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ABSTRACT 

This  study  proposes  the  best  strategy  to  integrate  information  systems  to 
effectively  support  several  common  Department  of  Defense  initiatives,  in  line 
with  Corporate  Information  Management  and  Total  Quality  Management 
principles.  This  research  examines  Computer-aided  Acquisition  and  Logistics 
Support/Concurrent  Engineering,  Electronic  Commerce/Electronic  Data 
Interchange,  Modernization  of  Defense  Logistics  Standard  System,  and  the 
Defense  Information  System.  The  study  proposes  an  interchange  architecture 
on  top  of  the  OSI-compliant  Defense  Information  System,  which  serves  as  a 
telecommunications  infrastructure,  for  multimedia  and  hypermedia  data 
interchange.  This  interchange  architecture  is  necessary  to  successfully 
implement  the  functions  and  applications  of  DOD  activities. 
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I.  INTRODUCTION 

Department  of  Defense  (DOD)  is  promoting  Total  Quality  Management 
(TQM)  at  the  executive  levels.  However,  as  in  the  case  of  implementing 
Electronic  Commerce/Electronic  Data  Interchange  (EC/EDI)  and  Computer 
Aided  Acquisition  and  Logistics  Support/Concurrent  Engineering  (CALS/CE), 
there  is  a  need  to  practice  more  TQM  on  a  more  formal  basis.  As  Verity  (1991) 
suggests,  customers  have  automated  virtually  all  the  easy  tasks  they  can  find: 
payroll,  financial  accounting,  inventory,  etc.  In  DOD,  even  these  easy  tasks 
have  not  been  done  efficiently  or  effectively.  Instead  of  automating  the  way 
DOD  had  done  business  for  many  years,  DOD  should  have  re-engineered  the 
process,  and  then  applied  computer  technology  to  the  system.  A  Corporate 
Information  Management  (CIM)  principle  states  that  you  must  first  simplify 
the  business  process  before  you  computerize.  Technology  should  not  be  applied 
until  you  are  sure  the  organization  can  implement  the  changes,  according  to 
Strassman  (June,  1991).  DOD  is  not  alone  in  having  failed  to  re-engineer 
processes  before  automating  them  over  the  last  two  decades.  Re-engineering 
of  the  processes  is  what  the  high-level  executives  have  been  searching  for 
during  the  past  20  years.  After  re-engineering  the  entire  way  daily  business 
is  done,  productivity  may  go  up  or  sales  may  increase.  According  to  Verity 
(1991),  the  re-engineering  market  will  reach  $15  billion  in  1995.  In  the  past 


DOD  has  let  technology  be  the  driver  instead  of  the  workflow.  It  is  not  too  late 
to  rethink  EC/EDI  and  CALS/CE  in  the  much  bigger  environment  instead  of 
treating  them  as  other  islands  of  automation  that  have  persisted  for  the  last 
decade.  DOD  should  impose  the  CIM  principles  on  the  initiatives  discussed  in 
this  research  immediately  by  speeding  up  the  adoption  of  Open  Systems 
Interconnection  (OSI)  and  the  introduction  of  multi-level  security  into  the 
information  systems  standards,  according  to  Strassman  (June,  1991). 

When  we  look  at  the  diversity  of  the  DOD  and  the  number  of  initiatives 
started,  you  cannot  help  but  wonder  how  anyone  can  understand  what  is  going 
on  with  information  resources.  This  research  will  attempt  to  define  the 
underlying  infrastructures  to  effectively  support  several  of  DOD's  initiatives, 
especially  CALS/CE,  EC/EDI,  MODELS,  and  DIS.  All  businesses  actually  rely 
on  various  types  of  information  which  are  conveyed  on  documents.  The 
multimedia  presentations  one  can  see  from  high  technology  computer 
companies  demonstrating  their  products  are  just  a  taste  of  what  is  to  come  in 
the  future. 

Business  processes  have  evolved  over  the  past  30  years  but  have  only  just 
begun  to  be  re-engineered  as  technology  matures.  Unfortunately,  DOD  is 
already  several  years  behind  industry  and  with  current  policies  will  fall  even 
further  behind  unless  some  strategic  changes  are  made  soon  and  strictly 
enforced. 


This  research  examines  these  common  DOD  initiatives  and  tries  to  show 
how  an  interchange  architecture  conforming  to  OSI  can  provide  an  effective 
telecommunications  infrastructure  and  define  multimedia  and  hypermedia 
interchange  standards  to  support  necessary  functions  and  applications  for 
EC/EDI,  CALS/CE,  and  MODELS.  The  primary  research  questions  this  study 
are: 


•  What  is  the  best  strategy  in  terms  of  standards  to  successfully  implement 
EC/EDI  and  CALS/CE? 

•  What  protocols  are  the  best  to  use  in  order  to  communicate  with  industry 
and  within  DOD? 

•  Is  it  feasible  to  use  DDN  for  multimedia  data  interchange  or  is  ISDN 
necessary? 

•  Is  the  intelligent  gateway  solution  feasible  or  is  there  a  better  platform 
or  solution? 


II.  CALS/CE:  TECHNICAL  AND  MULTIMEDIA 
DATA  INTERCHANGE 


A.   BACKGROUND 

1.  Paperless  Environment 

The  dream  of  a  paperless  office  surfaced  nearly  20  years  ago. 
Information  system  professionals  tried  their  best  to  progress  towards  the 
paperless  office  with  the  technology  they  had  available.  The  dream  has  never 
died  but  keeps  eluding  business  and  the  Government.  CALS/CE  is  the 
integration  of  manufacturing,  engineering,  and  logistics  support  to  a  near 
paperless  environment.  The  reduction  of  the  life  cycle  cost  of  weapon  systems 
through  competitive  parts  production  and  reduced  lead  times  can  be  effected 
by  implementing  CALS.  Maintaining  configuration  data  in  near  real-time  will 
provide  support  of  the  major  weapon  systems  like  the  Seawolf  submarine  and 
B2  stealth  bomber. 

2.  Policy  Direction 

Completely  isolated  islands  of  automation  need  to  be  interfaced  to 
form  integrated  systems.  The  changes  made  by  CALS  will  involve  enterprise 
wide  models/architecture  of  computing  and  communications.  The  re- 
engineering  of  workflows  will  involve  changing  both  the  DOD  and  business 
environment.  This  research  consolidates  information  resource  initiatives  such 


I 


as  CIM,  CALS,  EC/EDI,  and  MODELS  in  the  spirit  of  Corporate  Information 
Management  and  Total  Quality  Management.  Although  the  islands  of 
automation  are  to  be  integrated  in  the  weapons  systems  area,  many  CALS 
proponents  were  creating  another  island  of  automation  called  CALS/CE.  Many 
more  individuals,  both  in  business  and  DOD,  realize  now  that  CALS  is 
applicable  to  much  more  than  acquisition  and  procurement.  Expanding  global 
markets  and  shrinking  DOD  markets  have  reduced  the  need  for  new  weapon 
systems  and  called  for  more  modification  and  maintenance  of  old  weapon 
systems.  Strassman  (July,  1991)  states  that  the  Technical  Integration  Manager 
of  the  DISA  will  develop  and  maintain  technical  and  data  architectures  which 
impact  the  Functional  Integration  Manager  and  ensure  technical  integration 
throughout  functional  areas  with  the  technical  and  data  architectures. 
Unfortunately,  CALS/CE  technical  and  data  architectures  are  being  developed, 
maintained  and  integrated  without  regards  to  other  similar  DOD  initiatives. 
What  began  as  CALS  several  years  ago  should  now  be  looked  upon  as 
Computer-Aided  Acquisition  Logistics  Support  Migration  Systems  and  not  just 
CALS. 

3.      CALS/CE  Objectives 

The  objectives  of  CALS/CE  from  Dobey  (1989)  are: 


•   Develop  and  test  data  interchange  and  access  standards  to  create  a 
shared  information  environment 


•   Provide  high  risk  technology  development  funding 


•  Establish  contract  requirements  and  incentives  for  industry 

•  DOD-wide  implementation 

B.      REQUIREMENTS 

1.  MIL-HDBK-59  CALS  Program  Implementation  Guide  (1988) 

The  Handbook  (1988)  gives  "guidance  to  personnel  responsible  for  the 
acquisition  and  use  of  weapon  system  technical  data  to  assist  in  transitioning 
from  paper-intensive  processes  to  digital  data  delivery  and  access."  There  are 
two  methods  for  digital  delivery  or  digital  access  to  the  IWSDB:  data  transfers 
are  currently  done  by  magnetic  tape  or  DDN.  Generic  guidance  is  given  in  the 
following  application  areas:  1)  technical  manuals;  2)  engineering  drawings, 
specifications,  and  book-form  drawings;  3)  LSAR,  (Logistic  support  analysis 
record  data  MIL-STD-1388-2B);  and  4)  training  materials.  The  Handbook  also 
addresses  database  and  telecommunications  security. 

2.  Contractor  Integrated  Technical  Information  Service  (CITIS) 

A  critical  portion  of  CALS  is  the  establishment  of  distributed  data 
bases  between  DOD  and  contractors.  DOD  will  have  access  to  contractor 
generated  and  contractor  maintained  databases  of  weapon  system  data. 

3.  Joint  Uniformed  Services  Technical  Information  System 
(JUSTIS) 

DOD  will  also  have  distributed  databases  storing,  retrieving,  and 

processing  technical  data.  The  Interactive  Electronic  Technical  Manual  (IETM), 


with  multimedia  (or  hypermedia)  capability,  will  have  access  to  these 
engineering  drawing  repositories.  The  drawings  will  extensively  use  CAD  to 
integrate  design  and  design  analysis  processes.  Such  technical  information 
integration  will  be  called  JUSTIS  (Joint  Uniformed  Services  Technical 
information  system).  It  will  provide  the  infrastructure  for  managing  technical 
manual  data  in  all  formats  in  the  integrated  weapon  system  data  base. 

4.      CE/PIE  (Concurrent  Engineering/Parallel 
Integrated  Engineering) 

This  is  a  process  for  continuously  refining  and  defining  the  product 

by  considering  all  elements  of  product  life  cycle  management.  The  last  phase 

of  Life  Cycle  Management  uses  the  Total  Quality  Management  techniques  of 

continously  reviewing  the  process  according  to  DOD  Directive  7920.1  (1988). 

This  helps  insure  a  successful  product. 

C.   DATA  INTERCHANGE  STANDARDS  AND  PROTOCOLS 

CALS  standardization  includes  three  areas  that  will  not  be  examined 
here:  functional  requirements,  data  management  and  access  standards,  and 
application  guidance.  The  two  areas  that  will  be  discussed  in  detail  are  data 
interchange  standards  and  communication  protocols.  Data  interchange 
standards  are  common  rules  for  digital  interchange  of  technical  information 
and  will  be  the  focus  of  CALS  Phase  I. 


1.  MIL-STD-1840A  Automated  Interchange  of 
Technical  Information  (1987) 

This  is  the  master  document  for  all  military  specifications  through 

which  the  CALS  standards  will  be  published.  The  original  MIL-STD-1840  was 

published  by  the  Air  Force  in  1986  and  the  MIL-STD-1840A  by  NIST  in  1987 

through  an  interagency  agreement.  It  is  updated  annually.  The  main  technical 

concept  is  that  of  a  digital  envelope  which  organizes  files  of  digital  data  into 

a  deliverable  document.  A  document  can  be  complex.  For  example,  technical 

manuals  contain  SGML  text  files,  raster  and  CGM  illustration  files.  The 

original  MIL-STD-1840  contained  the  IGES,  SGML,  RASTER,  and  CGM  which 

have  since  developed  into  standards  by  themselves. 

2.  MIL-D-28000  Initial  Graphics  Exchange  Specification 
Computer  Aided  Design  (IGES  CAD)  Vector  Graphics 

This  standard  defines  the  digital  representation  for  communication 

of  product  data  between  dissimilar  computer  aided  design  systems.  It  is  also 

known  as  ANSI  Y14.26M.  It  defines  the  interchange  format  between  CAD 

systems  into  four  classes:  1)  engineering  drafting  Class  II;  2)  mechanical  three 

dimension  models  Class  IV;  3)  electronic  circuit  design  Class  III;  and  4) 

technical  publication  illustrations  Class  I.  The  graphics  are  represented  in 

ASCII  format  and  already  supported  by  30  CAD  vendors.  The  Navy  EDMICS 

(Engineering  Data  Management  Information  and  Control  System),  Air  Force 

EDCARS  (Engineering  Data  Computer  Assisted  Retrieval  System),  Army 

DSREDS  (Digital  Storage  and  Retrieval  Engineering  Data  System)  are  current 
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projects  (Smith,  1990).  This  standard  is  developing  into  the  Product  Data 
Exchange  Specification  (PDES). 

3.  MIL-D-28001  Standard  Generalized  Markup  Language  (SGML) 

This  standard  is  for  automated  publishing  of  page  oriented  text, 
meets  markup  requirements,  and  generic  style  specification  for  electronic 
printed  output  and  exchange  of  text  and  hypertext.  SGML  is  critical  for 
hypermedia  data  interchange.  The  standard  is  also  known  as  ISO  8879 
Information  Processing-text  and  Office  Systems-Standardized  Markup 
Language  (SGML).  Other  standards  used  with  SGML  are:  DSSSL  (Document 
Style  Semantics  and  Specification  Language)  for  output  specifications;  SPDL 
(Standard  Page  Definition  Language)  for  data  delivery;  and  FOSI  (Formatting 
output  specification  instance).  SGML  is  used  for  printing  technical 
publications,  composition  processing  functions,  defining  output  specifications 
of  typographic  tags  and  format  rules,  and  displaying  the  composed  document. 

4.  MIL-R-28002  GROUP  4  RASTER  Facsimile 

This  standard  sets  requirements  for  raster  graphics  representation 
in  binary  format  or  bit  map  graphics  that  have  been  compressed  to  reduce  file 
size  and  transmission  time.  There  are  two  types  of  raster  graphics.  In  Type  I 
(untiled,  which  is  FIPS  150),  the  default  mode  is  200  pels  per  inch  with  Group 
4  encoding. 


Type  II  (tiled)  defines  a  tile  as  a  rectangular  region  in  a  layout  object 
in  which  all  such  regions  have  the  same  dimensions.  No  part  of  any  tile 
overlaps  any  other  tile.  Group  4  raster  permits  compression  and  decompression 
in  parallel  on  the  drawing  tiles  or  portion  of  the  drawing  tiles.  The  division  of 
tiles  can  be  individually  processed  to  reduce  the  size  of  the  transmission  line 
and  reduce  terminal  storage  requirements.  Type  II  is  used  for  oversize 
documents  such  as  large  engineering  drawings. 

5.  MIL-D-28003  Computer  Graphics  Metafile  (CGM) 

This  standard  is  for  the  digital  representation  for  communication  of 
illustration  data  between  high  resolution  graphics  workstations.  Unlike  IGES, 
which  is  for  CAD  workstations,  it  is  based  on  line  segments.  The  metafile 
includes  allowable  output  primitives  and  attributes  used  to  compose 
illustrations.  The  standard  is  also  known  as  ANSI  X3.122,  FIPS  128,  and  ISO 
8632.  This  standard  is  for  picture  descriptions  and  illustrations  in  technical 
manuals. 

6.  Communication  Protocols 

a.     Short  Term 

In  the  short  run,  DDN  will  be  used  for  transmission  of  CALS 
data.  Most  large  drawings,  which  are  stored  on  magnetic  media  such  as  tapes, 
floppies,  or  optical  disks,  will  have  to  be  compressed  as  much  as  possible  to 
reduce  file  size  and  transmission  times.  Unfortunately  most  engineering 
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drawings  are  very  large,  and  even  with  compression  techniques  still  require 
several  hours  to  transmit  over  DDN. 

b.     Long  Term 

According  to  Lycas  (1989),  CALS  data  will  be  interchanged  using 
OSI  protocols  such  as  X.400  Message  Handling  System  (MHS)  and  File 
Transfer  Access  and  Management  (FTAM).  Chapter  IV  will  discuss  all 
protocols  in  detail.  The  underlying  network  will  have  to  be  a  broadband 
switched  network,  not  a  traditional  packet-switched  network  like  DDN. 

D.      NEW  INFRASTRUCTURES 

1.      CALS  Test  Network  (CTN) 

The  CTN  was  created  to  demonstrate  CALS  standards  and  test  their 
effectiveness  under  the  U.S.  Air  Force  Logistic  Command  leadership.  It  is  a 
joint  DOD-Industry  program  for  applications  testing,  prototype  computer 
product  conformance  testing,  and  prototype  data  acceptance  testing.  The 
testing  is  done  in  laboratories  and  uses  controlled  live  data.  The  standards 
discussed  previously  will  be  required  for  contractors,  subcontractors,  and 
vendors  desiring  to  do  business  in  the  Industrial-Military  Complex.  Selected 
defense  contractors,  laboratories,  the  Army  CALS  testbed,  and  other 
Government  sites  make  up  the  CTN. 
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2.  Industrial  Networks 

General  Motors  Corporation  developed  a  global  data  communications 
network  internally  and  has  thousands  of  trading  partners  internationally.  GM 
has  always  been  one  of  the  major  driving  forces  in  the  Industrial-Military 
Complex.  GM  developed  its  command  and  control  network  from  a  baseline 
much  like  DOD  developed  DDN,  but  GM  has  committed  many  more  resources 
into  networking  than  DOD.  Connectivity  between  DOD  and  large  industrial 
networks  has  the  potential  to  totally  change  the  way  business  is  done. 

3.  FTS-2000  and  ISDN 

DeLaura  (1986)  first  analyzed  data  communication  requirements  for 
CALS.  DeLaura  (1987)  concluded  that  DDN  could  not  provide  adequate 
support  for  the  very  large  documents  that  CALS  contractors  and  Government 
users  would  transmit.  Payne  (1990)  further  confirmed  that  bulk  transfers  could 
not  be  adequately  performed  using  DDN.  CALS  data,  being  multimedia  and 
hypermedia  information,  requires  very  high  speed  which  must  include  FDDI 
and  ISDN. 

4.  CALS  Operational  Resource  Information  System  (CORIS) 

CORIS,  like  CTN,  is  based  on  a  distributed  database  that  logically 
integrates  engineering,  logistics,  and  manufacturing  databases.  A  data 
communications  infrastructure  other  than  DDN  will  be  necessary  to  implement 
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CALS.  A  CALS  Information  Manager  will  provide  directory  services,  data 
dictionaries,  and  indexing.  (CALS  Exposition,  1990) 

E.      OTHER  STANDARDS  FOR  CALS 

Several  other  international  standards  will  be  implemented  in  CALS  Phase 
II.  Most  of  the  following  are  application  specific: 

•  EDIF  (Electronic  Design  Interchange  Format)  for  integrated  circuit 
design. 

•  ODA/ODIF  (Office  Document  Architecture/Office  Document  Interchange 
Format)  for  presentation  and  layout. 

•  SPDL  (Standard  Page   Description  Language)  for  image  delivery  of 
technical  publications. 

•  IRDS  (Information  Resources  Dictionary  System)  for  data  elements. 

•  SQL  (Structured  Query  Language)  for  data  access. 

•  STEP  (Standard  for  the  Exchange  of  Product  model  data   ISO  TC 
184/SC4. 


F.      SUMMARY 

The  strategy  of  implementing  CALS  must  be  reexamined.  This  research 
has  shown  many  of  the  current  standards  that  have  paved  the  way  for 
industry  and  defense  during  the  initial  years  of  the  CALS  initiative.  It  is 
imperative  that  DOD  use  CALS  to  prevent  existing  systems  from  becoming 
islands  of  automation  and  integrate  them  into  the  Corporate  Information 
Management  systems  as  soon  as  possible.  In  fact,  Strassman  (June,  1991) 
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states  that  one  of  needed  actions  in  speeding  up  the  business  process  redesign 
of  different  functional  processes  is  to  impose  CIM  principles  on  existing 
systems. 
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III.  EC/EDI  ELECTRONIC  COMMERCE/ELECTRONIC 
DATA  INTERCHANGE 


A.   BACKGROUND 

1.      EDI  Definition 

EDI  is  the  computer  to  computer  transmission  of  transactions 
primarily  between  external  organizations  computers  in  a  format  agreed  upon 
by  all  trading  partners.  EDI  is  used  as  a  means  of  eliminating  the  mail  lag 
time  into  a  matter  of  minutes  to  speed  electronic  commerce.  Industry  has  used 
EDI  for  direct  deliveries  and  just-in-time  inventory  techniques  for  several 
years.  Organizations  will  not  really  benefit  from  EDI  until  it  is  integrated 
internally  into  the  entire  organization  structure. 

Businesses  use  many  types  of  transactions  in  their  day  to  day 
operations  to  buy  and  sell  goods  and  services  from  each  other.  The  volume  of 
Government  business  necessitates  EDI,  especially  for  small  purchases.  There 
were  12  million  actions  under  $25,000  for  FY90  according  to  Drake  (1991).  The 
acquisition  and  procurement  system  can  use  EC/EDI  to  send  solicitations, 
awards,  invoices,  payments,  delivery  orders,  contract  accounting,  etc. 
Transactions  must  conform  to  standards  agreed  upon  by  all  trading  partners 
because  many  forms  of  business  documents  exist  in  the  business  environment. 
DOD  should  consider  evolving  toward  publicly  available  transactions  so  that 
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DOD  may  trade  with  all  trading  partners  conforming  to  the  ANSI  X12 
standard.  EDI  formats  define  all  possible  fields,  arrangement,  and  use.  For 
example,  ANSI  X12  has  defined  the  EDI  transaction  set  for  CALS  data. 

MODELS  addresses  the  DOD  internal  transaction  processing. 
MODELS  began  in  1984  as  a  modernization  of  the  DLSS  (Defense  Logistics 
Standards  Systems).  DOD  revised  MODELS  transactions  to  become  more  like 
EDI  syntax. 

Deputy  Secretary  of  Defense  Taft  directed  that  DOD  make  maximum 
use  of  EDI  for  the  paperless  process  of  all  business  related  transactions  in  May 
1988.  Assistant  Secretary  of  Defense  (Production  and  Logistics)  received 
responsibility  for  establishing  guidance  that  will  result  in  "..acceptance  of  EDI 
as  the  normal  way  of  doing  business  with  DOD  by  the  early  1990s."  The 
Assistant  Secretary  of  Defense  (P&L)  designated  the  DLA  (Defense  Logistics 
Agency)  as  DOD's  Executive  Agent  for  EDI  and  Data  Protection.  However,  the 
entire  excecutive  agent  procedure  may  change  as  a  result  of  Corporate 
Information  Management  Reviews.  In  fact,  Strassman  (July,  1991)  states  that 
DISA  will  manage  DOD-wide  standards  for  information  technologies  and 
architecture  in  November  1990,  Defense  Management  Report  Decision  941, 
Implementation  of  EDI  in  DOD  proposed  milestones  and  a  level  of  investment 
for  EDI. 
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2.      EC  Definition 

Electronic  Commerce  is  the  integration  of  EDI,  E-mail,  bulletin 
boards,  EFT,  and  similar  techniques  into  an  electronically  based  system  for  all 
DOD  business  functions  to  include  government  procurements  and  acquistion, 
payment,  supply  management,  transportation  base  operations,  contract 
administration,  maintenance,  and  fuels.  EC  will  put  in  place  necessary 
systems,  capabilities,  and  procedures  that  will  fundamentally  alter  the 
business  processes  and  daily  operations  from  a  paper  intensive  environment 
to  a  nearly  paperless  environment.  CIM  systems  data  standards  and 
architectures  must  be  developed  rapidly  and  applied  to  EC  before  much  further 
work  is  done  according  to  Strassman  (July,  1991). 

EC  will  rely  on  subsystems  which  will  resemble  many  of  the  CALS 
subsystems.  According  to  Drake  (1991)  the  first  subsystem  will  be  an  electronic 
market  consisting  of  an  electronic  information  broker,  electronic  classifed  ads 
and  advertising,  electronic  product  and  corporate  profiles,  and  electronic 
common  bulletin  boards.  The  second  subsystem  will  be  an  integrated 
distributed  database  with  an  interorganizational  database  and  electronic  report 
programs.  The  third  subsystem  will  use  EDI  transaction  sets  for  accessing  and 
ordering  and  exchanging  technical  data. 
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B.      REQUIREMENTS 

EC/EDI  has  many  requirements  that  this  research  will  examine  together 
with  the  CALS/CE  requirements  to  form  a  basis  for  multimedia  data 
interchange. 

1.      DLA  Tasks 

The  Electronic  Commerce:  A  Strategic  Plan  for  DOD  (1990)  specifies 
the  tasks  for  DLA  as  follows: 


•  Use  established  industry  transaction  standards,  readily  accessible 
technology,  and  commercially  available  products  and  services. 

•  Develop  and  maintain  implementation  guidelines,  establish  support 
agreements,  and  provide  configuration  management  translation  software. 

•  Provide  common-user  support  for  all  DOD  activities,  including  central 
directories  and  PLUS  (Protection  of  Logistics  Unclassified/Sensitive) 
initiatives. 

•  Establish  pilot  applications  for  testing  new  Electronic  Commerce  concepts 
and  products. 

•  Participate  in  industry  standard  committees. 

•  Provide  a  "single  face  to  industry"  on  all  EDI  and  PLUS  activities. 

•  Establish  a  nucleus  of  expertise  to  promote  and  aid  early  implementation 
of  Electronic  Commerce. 

•  Accessability  to  proven,  cost-effective,  and  standardized  Electronic 
Commerce  software,  hardware,  and  communications,  and  accessability  to 
clear,  standard  guidance  on  implementing  Electronic  Commerce. 

•  Effective,  knowledgeable  representation  in  national  and  international 
standards  development  processes. 

•  Dynamic,  highly  competent  focal  point  on  all  matters  related  to  EC. 
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Automate  the  generation,  processing,  coordination,  distribution,  and 
reconciliation  of  every  business  transaction,  from  requistioning  to  base 
operations,  throughout  the  DOD  without  need  for  hard-copy  media. 


2.  Business  and  Technical  Data 

EC  will  provide  prospective  business  offerors  the  business  and 
technical  data  needed  to  make  decisions  and  to  prepare  cost  estimates. 
Businesses  may  transmit  engineering  drawings  and  specifications 
electronically  when  the  procurement  requires  a  shortened  solicitation  cycle. 
This  research  will  show  how  most  businesses  may  eventually  transmit  EDI 
transactions  and  accompanying  data  files  in  an  E-mail  envelope  (X.435)  to 
vendors  in  the  electronic  directory  service  (X.500). 

3.  Interactive  EDI 

Interactive  EDI  provides  the  mechanism  for  trading  partners' 
applications  to  communicate  in  a  direct  on-line  manner  beyond  that  of  fast 
batch  communications,  according  to  the  X12C  Subcommittee  (1991). 

a.     Definition 

I-EDI  is  the  ability  for  two  computing  devices  to  exchange  X12 
information  in  a  direct,  conversational,  and  negotiable  mode.  Under  batch  EDI, 
transactions  are  transferred  in  an  asynchronous  mode  going  the  other  way. 
The  transaction  one  partners  sent  is  not  synchronized  with  the  transaction. 
However  a  transaction  is  very  likely  to  be  in  response  to  previous  transaction 
going  the  other  way.  Fast  batch  retains  the  communication  connection  in 
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anticipation  of  a  transaction  being  returned  by  a  partner  in  response  to 
another  partner.  I-EDI  contains  blocks  of  EDI  data  in  a  peer-to-peer  session 
performing  the  translation  function  between  each  peer's  application. 

6.     Benefits 

Benefits  of  the  interactive  approach  depend  on  the  ability  of  the 
user  to  act  quickly.  The  extent  to  which  the  trading  partner  is  automated,  the 
greater  the  reduction  in  connection  time.  The  best  case  would  be  an  interactive 
user  agent  that  would  react  to  results  of  searches  on  predefined  rules  rather 
than  wait  for  human  reaction.  During  multi-level  searches  I-EDI  lets  the  user 
start  from  a  previous  point  so  that  the  search  process  does  not  need  to  start 
from  the  beginning  again. 

4.      Document  Translation  System  Requirements 

a.     EDI  Translation  Software 

EDI  translation  software  reformats  application  data  into  an 
acceptable  EDI  standard  format,  as  defined  by  X12.  EDI  standards  change 
every  six  months  and  the  means  to  update  these  easily  is  by  maintaining 
translation  tables  separately  from  the  applications.  Vendors  for  most  EDI 
software  provide  translation  table  updates  to  keep  the  system  current.  Generic 
interface  files  between  the  corporate  applications  and  EDI  software  need 
customization  for  the  specific  user  and  can  be  customized  for  more  than  one 
user.  The  actual  translation  process  modules  may  perform  the  integration  of 
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1)  the  raw  data;  2)  trading  partner  information,  and  3)  the  standards  tables 
into  a  formatted  EDI  transmission  ready  to  pass  to  the  communication 
software. 

6.     Data  Mapping 

Data  Mapping  is  essential  to  the  successful  operation  of  the  EDI 
applications.  Data  mapping  is  required  at  the  interface  between  EDI 
translation  software  and  applications.  A  small  translator  which  prints  out  a 
paper  copy  for  action  and  accepts  input  from  a  keyboard  can  be  the  foot  in  the 
door  for  starting  EDI,  with  a  manual  data  mapping.  The  small  translator  can 
become  integrated  at  a  later  time  with  the  corporate  database.  Data  mapping 
maps  values  between  an  intermediate  flat  file  generated  by  EDI  translation 
software  and  the  appropriate  locations  in  the  database.  The  ultimate  goal  is 
application-to-application  EDI  in  which  data  mapping  is  integrated  in  the 
initial  design  of  the  database  or  corporate  information  system.  This  will  only 
be  possible  by  using  the  CIM  principle  of  providing  interoperable  vendor- 
independent  systems  assembled  from  standard  components  with  distributed 
databases. 

c.      EDI  software  alternatives 

DOD  can  make  or  buy  EDI  software.  The  Lawrence  Livermore 
National  Labs  has  developed  Ascent  software  in  cooperation  with  Control  Data 
Corporation.  This  software  is  now  offered  on  an  U.S.  Air  Force  contract  as  off- 
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the-shelf  software.  Many  vendors  have  developed  off-the-shelf  EDI  software 
which  DOD  could  use  by  simply  deciding  on  parameters  for  the  fields.  The  off- 
the-shelf  software  allows  a  user  to  create  his  own  transaction.  Finally,  value 
added  network  or  third  party  networks  support  EDI  gateways  to  multivendor 
platforms  of  trading  partners  throughout  the  world.  These  VANs  are  much 
more  capable  than  only  using  one  type  of  vendor  software  because  the 
translation  process  is  performed  by  the  VAN.  VANs  are  one  of  the  most 
popular  methods-approximately  25%  of  all  EDI  users  use  VANs,  according  to 
Drake  (1991). 

d.     EDI  hardware  alternatives 

Microcomputer  stand-alone  systems  are  usually  used  by  a  small 
company  with  a  small  amount  of  data,  or  by  an  EDI  system  not  integrated 
with  the  applications.  The  cost  of  an  adequate  PC  286  AT  compatible  is  now 
approximately  $700;  2400  baud  modem  $100;  24-pin  dot  matrix  printer  $250; 
communication  software  $100;  and  EDI  translation  software  $400-1000.  So  the 
total  cost  of  an  adequate  system  can  be  approximately  $2,000-2,500  depending 
on  the  type  of  EDI  software  purchased. 

Microcomputer  interfaces  with  outside  communications,  contain 
EDI  translation  software  and  can  have  direct  hardwire  interfaces  with  a 
mainframe.  A  mainframe  receives  all  EDI  data  through  one  communication 
port  in  the  communication  processor  and  processes  the  raw  data.  Using  the 
mainframe  provides  greater  growth  potential  as  EDI  committments  increase. 
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e.      EDI  Communications  Options 

(1)  Direct,  point-to-point  connection.  This  option  was  used 
initially  until  more  companies  began  using  EDI.  When  multiple  trading 
partners  exist  establishing  and  maintaining  many  secure  communication 
channel  connections  among  them  greatly  increase  costs. 

(2)  Value  Added  Networks  (VAN).  Value  added  networks 
address  the  cost  issues  of  a  point-to-point  connection  by  minimizing 
compatibility  issues,  scheduling  problems,  and  providing  control  of  the 
environment.  Costs  vary  depending  on  the  network,  volume  of  transactions, 
and  services  used  by  the  trading  partners.  VANs  provide  the  following: 


•  Store  and  forward  services  in  which  mailboxes  store  inbound  transactions 
for  the  recipient. 

•  Compliance  checking  services  to  determine  if  transactions  are  formatted 
as  agreed  upon  by  the  trading  partners. 

•  Translation/conversion  services  into  the  format  agreed  upon  by  the 
trading  partners. 

•  Interconnection  services  to  allow  customers  to  deal  with  trading  partners 
in  other  networks  through  gateways. 


f.      EDI  Implementation  Problems 

Several  problems  may  affect  the  implementation  of  EDI: 

•   Using  proprietary  formats  instead  of  international  or  national  standards. 
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•  Promising  more  than  you  can  deliver.  EDI  is  very  limited  in  scope  at  this 
time. 

•  Prescribing  EDI  as  a  do  all. 

•  Converting  existing  systems  to  EDI  without  analyzing  the  process  or  re- 
engineering  following  CIM  principles  and  TQM  methods. 


5.      Electronic  Contracting 

According  to  Drake  (1991)  EDI  in  procurement  should  be  one  of  the 
first  functional  areas  within  the  Federal  Government  to  greatly  benefit  from 
EDI  in  a  very  short  period  of  time. 

a.  EDI/EFT 

General  Electric  (GE)  Information  Systems  provide  a  large 
portion  of  EDI/EFT  services  for  DOD.  Payments  from  66  payment  offices  to  10 
different  GE  businesses  totalled  $8  Billion  in  1990,  according  to  the  Electronic 
Contracting  Conference  (1990).  Of  the  $8  Billion,  GE  electronically  collected  $3 
Billion  and  provided  electronic  remittance  advice  on  an  additional  $3  Billion. 
The  major  trading  partners  are  the  Defense  Contract  Administration  Service 
Payment  Centers  and  Kirtland  Air  Force  Base.  GE  used  ANSI  standards  not 
consistent  with  existing  DOD  EDI  efforts. 

b.  Paperless  Contracting 

The  goal  of  electronic  contracting  is  to  integrate  paperless 
processing  to  include  wordprocessing,  spreadsheets,  databases,  expert  systems, 
and  EDI  at  the  contract  specialist's  desk.  The  main  hurdles  for  paperless 
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processing  are  the  efficient  processing  of  multimedia  data,  digital  signature 
and  multi-level  security.  A  digital  signature  is  a  symbol,  generated  through 
electronic  means  to  verify  the  sender's  identity  and  the  integrity  of  the 
information  received  from  the  sender.  It  may  represent  a  person  or 
organization.  GSA  has  accepted  digital  signatures  which  use  Public  Key 
Encryption  (PKE)  as  legally  binding,  according  to  the  InfoSec  Conference 
(1991). 

Networking  is  essential  to  successfully  provide  connectivity  between 
contract  offices  and  the  customers.  The  contract  office  receives  the  procurement 
request  from  the  customer  and  creates  an  electronic  file  folder  placed  in  an 
electronic  filing  cabinet.  A  decision  support  system  which  is  menu  driven  will 
serve  as  the  procurement  process  guide  to  follow.  Coordination  with  technical 
representatives,  legal  counsel,  small  business  specialists,  and  with  the 
customer  will  occur  through  EDI  and  E-mail. 

EDI  applications  in  the  Federal  Government  are  few  compared  to 
numerous  commercial  applications.  Two  current  EDI  applications  are:  1) 
Defense  General  Supply  Center's  Paperless  Ordering  Placement  System;  and 
2)  GSA  Federal  Supply  Service  use  of  purchase  orders.  Their  main  objectives 
are  to  eliminate  duplication  of  work,  speed  up  the  procurement  process,  and 
eliminate  paper. 

Expert  systems  should  assist  the  contract  manager  in  preparing  the 
solicitation,   evaluating  the   proposals,   advising  about  regulations,   source 
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selection,  contract  selection,  and  warranty  analysis.  Electronic  contracting  also 
assists  the  program  manager  in  generating  the  acquistion  package 
documentation,  tracking  a  purchase  request  through  the  process,  accessing 
acquistion  regulations,  and  utilizing  acquisition  planning  tools.  Paperless 
contracting  is  nearly  possible  with  the  integration  of  contracting  subsystems 
over  networks  using  EDI. 

C.      STANDARDS  AND  STRATEGY 

Different  standards  in  the  U.S.  compared  to  the  international  standards 
may  cause  some  difficulty  in  worldwide  enterprises. 

1.     ANSI  X12 

The  ANSI  ASC  (Accredited  Standards  Committee)  X12  was  chartered 
in  1979  to  develop  uniform  standards  for  inter-industry  electronic  interchange 
of  business  transactions.  X12  operates  under  the  procedures  of  ANSI  with  the 
subcommittees  listed  in  the  Appendix.  The  ANSI  ASC  full  committee  has  a 
membership  of  approximately  500  members  who  vote  on  issues.  The  ASC  has 
a  formal  process  for  drafting  standards  for  trial  use.  This  process  includes  the 
following:  1)  planning  phase;  2)  development  phase;  and  3)  ASC  X12  review 
and  approval  phase. 
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a.     X12  Transmission  Concept 

(1)  Data  Segments.  Each  X12  message  consists  of  data 
segments,  data  elements,  and  a  transmission  envelope  to  form  a  transaction 
set.  A  data  segment  begins  with  its  identification  code,  is  followed  by  a  specific 
sequence  of  mandatory  and  optional  segments,  and  ends  with  a  segment 
terminator  character.  Data  segments  must  be  selected  from  the  X12  Data 
Segment  Directory  which  specifies  the  make  up  of  each  transaction  set  by  data 
segment.  Each  data  segment  consists  of  a  sequence  of  data  elements  of  variable 
length  separated  by  a  separator  character.  Data  elements  are  classifed  as 
identifiers,  numeric,  decimal,  character,  string,  date,  time,  and  binary  found 
in  the  X12  Data  Element  Dictionary.  See  Figure  1. 

(2)  EDI  Envelope.  An  envelope  contains  a  transaction  set 
header  which  identifies  the  type  of  transaction  set  and  a  trailer  which  contains 
information  verifying  the  number  of  segments  in  the  transaction  set.  Similar 
type  transaction  sets  may  be  transmitted  as  one  functional  group  in  a  single 
envelope. 

(3)  X12  Infrastructure.  According  to  the  X12  Information 
Manual  (1991),  the  X12  standard  consists  of  basic  functions  to  make  up  a 
standard  operating  procedure  and  format  which  consists  of  the  following: 

•  Start  and  end  validation. 

•  Sender  and  destination  identification. 
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X12  Transaction  Set  Example 


Transaction  Set 


Invoice 


Effi,  10th  Infantry  Ba: 
ATTN;  Supply  Officer 
For:  Ord  CA  93922 


bMmmbl 


Total 


NSN     Cost 
^01-^.95 

/324  79.99 


Data  Elements 


186.34 


Remit  to:   ABC  Conpany 

211  Lighthouse  Ave. 
Pacific  Grove  CA  93941 


Functional  Group 


Figure  1.  X12  Transaction  Set  Example 

•  Senders  control  number. 

•  Separators  and  terminators. 

•  Data  set  identification. 

•  Time  and  date  stamp. 

•  Exchange  message  count. 

•  Telecommunications  protocol  interfaces. 


28 


•  Value  added  networks. 

•  Off-the-shelf  applications  software. 

b.     X12  Standard 

The  X12  standard  consists  of  four  main  parts  (Sokol,  1989).  The 
X12.3  Data  Element  Dictionary  specifies  the  name,  description,  type,  and 
minimum/maximum  lengths  of  each  data  element.  The  X12.5  defines 
Interchange  Control  Structures  which  is  the  EDI  envelope.  The  X12.6 
Application  Control  Structures  which  are  the  formal  descriptions  of  the  EDI 
architecture.  The  X12.22  Segment  Directory  defines  segments  which  are  lists 
of  related  data  elements. 

2.      UN/EDIFACT  United  Nations  For  Administration  Commerce 
and  Transport 

X12  is  the  most  prevalent  standard  in  the  U.S.  However,  some 

industries  have  found  X12  inefficient.  Some  want  additional  fields  while  others 

would  like  to  delete  extra  fields  unnecessary  for  their  industry.  Even  though 

the  intra-industry  committees  have  tried  to  address  special  needs,  a  strong 

international  support  developed  for  an  international  standard.  A  few  United 

Nations  projects  to  unite  all  standards  around  the  world  exist.  The  most 

popular  worldwide  standard  is  EDIFACT.  DOD  has  adopted  X12  as  the  EDI 

standard  but  supports  the  convergence  of  X12  with  EDIFACT. 
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3.      CALS  MIL-STD-1840A  Data  Through  Transaction  Set  841 

a.  The  X12  Transaction  Set  841 

The  "Specification/Technical  Information  Transaction  Set" 
merges  Transaction  set  839  Technical  Information  and  841  Specifications 
together  according  to  Saltman  (1990).  ASC  X12  added  a  special  Government 
segment  for  CALS  to  use  MIL-STD-1840A  in  1989.  The  process  described  in 
Subsection  C.l  resulted  in  a  1989  ballot  vote  and  again  in  1990  by  ASC  X12. 
Currently,  the  X12  Procedure  Review  Board  approved  841  as  a  draft  standard. 

b.  File  Restructuring 

File  restructuring  of  an  1840  A  includes  the  declaration  file  in  the 
header  area  and  the  data  files  in  the  detail  area.  Multiple  files  forming  a  single 
document  would  allow  repetition  of  detailed  data.  The  trailer  area  will  be  used 
for  verification  and  authentication. 

c.  Government  (GOV)  Segment 

The  GOV  segment  added  to  the  841  transaction  set  consists  of 
three  main  data  elements:  (1)  The  item  description  qualifier  which  if  coded  MS 
means  that  the  following  data  elements  contain  a  record  of  the  declaration  file 
or  the  header  of  data  files  based  on  1840A;  (2)  The  record/file  qualifier  which 
contains  the  name  of  the  record  in  the  declaration  file;  and  (3)  The  record 
format  data  which  contains  codes  such  as  T2  for  two  text  files,  Q2  for  two 
IGES  files,  and  C2  for  two  CGM  files  in  the  transmitted  document. 
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Saltman  (1990)  proposes  that  a  total  of  10  GOV  segments  will 
be  in  841.  The  records  not  provided  in  the  GOV  segment  (1,2,6,9,  and  13)  will 
not  be  transmitted.  Five  additional  GOV  segments  must  be  added  and  the  data 
repeated  along  with  the  record  names  to  transmit  them. 

d.  Transaction  Set 

Data  mapping  of  MIL- STD- 1840 A  records  to  transaction  set  841 
segments  exist  for  IGES,  Raster,  CGM,  PDL,  gray  scale,  and  special  words 
files.  Each  transmitted  document  uses  its  own  841  transaction  set  which 
follows  the  one  before.  The  envelope  around  one  or  more  transaction  sets  in 
sequence  consists  of  the  functional  group  header,  GS,  and  the  functional  group 
trailer,  GE.  The  outer  envelope  outside  the  start  of  the  first  functional  group 
and  the  end  of  the  last  functional  group  consists  of  the  Interchange  Control 
Header,  ISA,  and  Interchange  Control  Trailer,  IEA,  according  to  Saltman 
(1990). 

e.  Data  Types  for  841 

The  types  of  technical  data  which  will  require  841  are: 

•  Engineering,  quality,  and  test  specifications. 

•  Design  analysis  and  review  packages. 

•  Technical  proposals  and  support  packages. 

•  Product  definition  data. 
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•  Technical  orders  and  manuals. 

•  Electrical  and  mechanical  interface  documents. 

f.      Interim  Solution 

The  X12  841  transaction  set  is  an  interim  solution  because 
transmission  costs  are  very  high  due  to  excessive  overhead.  A  successor  to  the 
X12  841  transaction  set  will  be  the  X.435  standard  which  is  discussed  in  detail 
in  Chapter  IV.C.  It  will  allow  E-mail  messages  to  carry  EDI  data,  CAD/CAM 
data,  and  text  data  in  the  same  envelope.  It  can  separate  these  different  data 
types  and  still  organize  the  electronic  message  into  body  parts  which  makes 
it  less  expensive  to  process.  Many  of  these  compound  documents  may  be  over 
one  gigabyte  in  length. 

4.      Electronic  Commerce:  A  Strategic  Plan  for  DOD 

DLA  proposed  a  very  high  level  implementation  plan  with  very  long 
completion  dates  for  the  following  implementation  activities:  (DLA,  1990). 

a.  Business  case  preparation 

This  justified  the  return  on  investment  for  EC. 

b.  Implementing  authority  development 

DLA  prepared  memorandums  for  Secretary  of  Defense  Offices 
which  gave  official  support  to  EC  initiative. 
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c.  Implementation  Baseline 

DLA  compiled  a  list  of  all  DOD  components  with  on-going  EDI 
projects.  This  was  done  to  identify  any  duplication  of  effort,  share  experiences 
with  other  components,  and  prevent  further  duplication. 

d.  Identification  and  Removal  of  Impediments 

DLA  reviewed  all  regulations  and  statutes  to  identify 
impediments  to  the  use  of  Electronic  Commerce.  They  then  developed  a  plan 
of  action  and  schedule  to  remove  the  obstacles 

e.  Implementation  Guidelines  Development 

DLA  prepared  standards,  rules,  and  conventions  for  EDI  between 
DOD  and  trading  partners. 

f.  Operational  Concepts  Development 

DLA  prepared  operational  concepts  for  the  following  functional 
areas  because  they  offered  greater  return  on  investment  than  other  areas: 

Finance  Centers 

Procurement  and  Contract  Administration 

Transportation 

Supply  Management 

Maintenance 

Fuels 

Base  Operations 


33 


g.      Configuration  of  Research  and  Development  Network 

DLA  formed  the  Electronic  Commerce  Experimental  Network  to 
test  new  translation  software,  hardware,  data  communications,  data  security 
techniques,  and  other  technological  advances  to  enhance  the  EC  program. 

h.     Installation  of  Pilot  Applications 

DLA  is  in  the  process  of  selecting  pilot  applications  from  the 
functional  areas  in  Section  f  above  to  develop  and  implement  in  a  real-world 
environment. 

i.      Preparation  of  Data  Dictionary 

DLA  is  in  the  process  of  preparing  and  publishing  an  EC  data 
dictionary  based  on  the  Logistics  Data  Resource  Management  System,  ANSI 
X12,  and  EDIFACT  data  dictionaries  to  insure  the  use  of  standard  data 
elements. 

j.      Development  of  Translation  Software 

DLA  is  investigating  the  possibility  of  buying  a  translation 
software  package  off-the-shelf  or  developing  it  in-  house  after  determining 
DOD's  translation  software  requirements. 

k.     Procurement  of  Hardware 

DLA  is  surveying  the  market  to  determine  what  computer 
hardware  will  best  meet  EC  users  needs  and  will  publish  a  preferred  products 
list. 
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/.      Development  of  Communications  Plan 

DLA  is  designing  a  communication  network  for  EC  which  must 
determine  the  type  of  protocols  and  standards  to  use.  This  research  will  help 
DLA  determine  the  best  strategy  to  follow. 

m.    Development  of  Security  Plan 

DLA  is  researching  how  to  incorporate  multi-level  security  and 
manage  the  crytographic  keys  required  for  the  systems. 

n.     Development  of  Small  Business  Plan 

As  part  of  the  developing  plan  DLA  conducted  a  small  business 
fair  in  Dayton,  Ohio,  in  April  1991  and  demonstrated  the  Government 
Acquisition  Through  Electronic  Commerce  (GATEC)  EDI  project  sponsored  by 
the  Wright  Patterson  Contracting  Center.  One  of  the  first  functional  areas  in 
which  a  very  high  ROI  is  expected  is  procurements  under  $25,000.  Small 
businesses  are  big  providers  of  products  and  goods  for  small  procurements. 

o.     Formulation  of  Marketing  and  Training  Plans 

DLA  is  developing  training  materials  on  EC  and  is  also  releasing 
official  articles  on  the  DOD  EC  program  for  publication  in  Government  and 
industry  trade  journals. 
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D.      OBSERVATIONS 

1.  EC/EDI  Increases  Competition 

All  interested  parties  can  receive  notices  of  all  opportunities  and  have 
access  to  the  solicitation  electronically  if  they  have  computers  and  EDI 
software.  The  Government  increases  the  amount  of  the  market  which  has  a 
chance  to  look  at  the  solicitation.  Small  businesses  may  use  EDI  with  PCs. 
However,  only  EDI  translation  software  is  readily  available  and  only  a  few 
business  software  packages  provide  EDI  capability.  CIM  initiatives  in 
procurement  and  contract  payment  should  be  integrated  with  EC  techniques. 
CIM  should  establish  a  target  date  for  all  DOD  transactions  to  use  EDI  based 
on  commercially  available  software. 

2.  EC/EDI  Changes  The  Way  We  Do  Business 

The  main  goal  of  EC  is  to  achieve  end-to-end  paperless  commerce.  EC 
facilitates  just-in-time  inventory,  direct  vendor  delivery,  and  use  of 
nondevelopmental  items.  The  biggest  cost  saver  is  the  elimination  of  large 
stockpiles. 

3.  Types  of  Procurements 

Indefinite  Delivery  Contracts  (IDC)  and  Basic  Ordering  Agreements 
(BOA)  have  become  a  very  popular  means  for  rapid  purchase  requirements. 
IDCs  attract  greater  market  interest  because  the  size  of  the  solicitation  may 
be    larger    than    normal.    For    example,    Desktop    III    and    Desktop    IV 
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microcomputer  contracts  allow  any  DOD  agency  to  order  computers  from  the 
contract.  The  IDC  is  completed  with  the  assumption  that  the  maximum  order 
limit  probably  will  not  be  reached.  Invitation  For  Bid  (IFB)  contracts  could  also 
give  a  good  ROI,  but  the  volume  compared  to  IDCs  and  BOAs  is  much  lower. 

4.      Electronic  Bulletin  Boards 

Electronic  bulletin  boards  used  to  publicize  contract  actions, 
integrated  vendor  databases,  and  third  party  information  brokers  should  be 
part  of  the  procurement  environment.  An  electronic  CBD  (Commerce  Business 
Daily)  divided  by  amount  and  type  of  supply  would  require  less  than  half  the 
time  when  compared  to  the  hard  copy  CBD  item  to  appear  to  the  public 
(Drake,  1991).  One  format  of  the  bulletin  board  would  be  X12  and  the  other  in 
plaintext.  Vendors  could  respond  with  EDI  transactions  to  the  DOD  address 
in  the  CBD.  One  copy  of  the  bulletin  board  could  be  only  in  the  DOD 
environment  and  another  copy  on  a  commercial  bulletin  board  because  of 
security  reasons.  The  commercial  bulletin  board  could  be  managed  by  a 
contractor  according  to  government  regulations  as  a  master  copy. 

If  the  industrial  infrastructure  exists,  then  a  distributed  multi-vendor 
database  could  reside  on  a  commercial  mainframe  accessed  through  a  gateway. 
A  request  for  quote  for  particular  items  from  a  DOD  user  to  a  vendor  could  be 
a  query  to  the  database  thru  the  gateway.  The  need  for  a  multi-level  secure 
database  exists  for  certain  procurements.  Oracle,  Inc.  for  example  provides  a 
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trusted   database.   These    same   considerations   are   present  in   the   CALS 
initiative. 

5.      Industrial  EDI  Base 

DOD  should  build  upon  the  large  installed  base  of  EDI  software  in 
the  private  sector  to  easily  access  DOD.  FTS2000  would  provide  access  to  the 
private  DOD  wide  area  network.  Autodin  and  the  messaging  part  of  DDN  will 
be  replaced  by  the  year  2000  with  DIS.  DOD  networks  should  become  linked 
with  Prodigy,  CompuServe,  Telenet,  and  Tymnet  to  provide  wide  access  to  all 
firms. 

a.     Information  Superhighways 

The  information  superhighway  systems  will  be  essential 
infrastructures  for  commerce  and  defense.  The  interstate  superhighways  will 
consist  of  individual  statewide  systems,  metropolitan  area  beltways,  with 
access  to  individuals  and  companies  no  matter  where  the  location. 
Interchanges  will  be  crucial  to  successful  information  transport  particularly  for 
traffic  flow  and  accidents  thru  electronic  gateways.  DOD  may  make  a  strategic 
error  if  they  choose  not  to  use  the  industrial  base  interstate  system  and 
continue  to  use  the  military  base  system  (DDN).  Industrial  information 
superhighways  will  provide  the  large  links  necessary  for  compound  documents 
routine  travel  (FTS  2000).  The  US  air  transport  system  provides  ultra  fast  long 
distance  transport  of  small  packages  or  bundles  of  information.  Similarly,  an 
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electronic  messaging  system  for  small  bundles  from  point  to  point  will  be  part 
of  the  information  superhighway  system.  This  information  superhighway,  in 
fact,  has  become  global  with  the  installation  of  fiber  optic  cables  across  the 
Atlantic  and  Pacific  Oceans.  DOD  must  recognize  that  the  cost  of  maintaining 
and  supporting  a  military  infrastructure  which  tries  to  duplicate  the  industrial 
infrastructure  is  already  cost  prohibitive  and  will  become  more  so.  The 
duplication  of  the  industrial  infrastructure  on  a  global  scale  would  be  futile. 
The  Air  Force  has  already  had  cost  overruns  while  operating  the  Worldwide 
Military  Command  and  Control  Systems. 

b.     EDI  X12  For  Document  Translation. 

DOD  should  use  X12  because  it  is  a  North  American  standard 
and  most  of  DOD's  business  contracts  are  within  the  United  States.  However, 
over  half  of  the  private  sector  does  not  use  X12.  But  all  vendors  wishing  to  do 
business  with  DOD  will  have  to  purchase  XI 2  software  because  DOD  adopted 
X12  as  the  DOD  standard.  DOD's  internal  formats  in  the  DLSS  are  being 
updated  to  nearly  X12  in  the  MODELS  program  because  of  some  unique  labels 
and  contents  of  DOD  fields.  If  no  X12  field  exists  for  DOD  unique  information, 
it  can  be  placed  in  an  optional  field  and  still  retain  its  format.  DOD  will 
develop  X12  implementation  guidelines  so  that  VANs  can  offer  X12  translation 
service  with  those  particular  DOD  parameters. 
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6.      EDI  Network  Architectures 

Several  EDI  network  architectures  are  available  to  exchange 
information  between  DOD  and  the  300,000  plus  vendors  currently  doing 
business  with  DOD  (Drake,  1991). 

Mixed  media  such  as  a  diskette  or  magnetic  tape  could  be  mailed 
between  trading  partners  and  only  requires  a  standard  format. 

Users  could  dialup  via  a  modem  and  establish  a  dedicated  link  for 
the  duration  of  the  session.  If  the  same  EDI  software  resides  on  both 
computers  no  translation  is  necessary.  If  there  is  different  E-mail  software, 
then  the  electronic  messaging  standard  X.400  could  create  an  envelope  around 
the  XI 2  transactions  with  addressing  information.  The  new  standard  X.435 
approved  in  June  1991,  called  PEDI,  retains  the  EDI  identification  within  the 
message  header.  This  allows  the  routing  of  the  EDI  message  without  the  need 
to  check  the  contents  of  the  message  between  various  E-mail  systems. 

E-mail  with  mailboxes  provided  by  the  trading  partner  computer  or 
by  a  VAN  would  require  the  sender  to  place  the  message  in  the  receiver's 
mailbox  and  be  notified  at  a  later  time  that  the  receiver  retrieved  it.  Both 
parties  do  not  need  to  be  on-line  at  the  same  time.  This  would  facilitate  the 
Electronic  bulletin  board  availability  to  all  vendors.  Most  private  networks  use 
X.400  as  their  E-mail  standard  and  unless  DOD  adopts  X.400  as  their  E-mail 
standard,  problems  with  allowing  messages  from  DOD's  proprietary  protocols 
to  X.400  will  prevent  widespread  use.  Private  networks  also  use  the  OSI 
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standard  X.500  to  provide  an  electronic  directory  with  electronic  addresses  of 
vendors  and  by  function  or  business.  DDN's  addressing  scheme  is  archaic  and 
does  not  interface  with  X.500.  DOD's  Defense  Automated  Addressing  System 
(DAAS)  would  provide  minimum  addressing  services  required  until  X.500  is 
adopted  by  DOD  which  would  again  eliminate  another  DOD  proprietary 
system.  DAAS  is  not  scheduled  to  begin  functioning  completely  until  the  year 
2000. 

Will  DDN  provide  sufficient  bandwidth  to  support  EDI  transactions? 
From  Payne  (1990)  initial  estimates  based  on  1988  volumes  would  produce  25 
gigabits  of  data  per  day  from  the  procurement  system  alone.  Transportation, 
fuels,  etc.,  will  also  have  the  same  amount  of  data.  By  1992,  at  least  one 
terrabit  of  data  will  be  transmitted  per  day,  if  CALS  data  is  shipped  in  an  EDI 
envelope.  Payne  (1990)  was  very  conservative  in  her  estimate  and  also  liberally 
assumes  that  very  high  speed  lines  (gigabits/second)  will  be  available  by  1995. 
A  backbone  infrastructure  may  approach  these  speeds  but  until  the  local 
subscriber  loops  upgrade  to  ISDN,  it  will  not  matter  how  high  the  speed  is  for 
the  backbone  because  the  chokepoint  will  be  the  local  access  line.  Any  thoughts 
about  DDN  being  upgraded  to  a  broadband  network  will  be  delayed  because 
of  budget  constraints.  Even  a  T-l  network  will  not  be  sufficient  to  transmit 
thousands  of  terrabits  of  data.  A  compound  CALS  document  containing  500 
engineering  drawings  with  text,  video  and  other  graphics  may  contain  nearly 
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one-half  terrabit  of  data.  It  may  not  be  uncommon  to  have  electronic  video 
teleconferences  reviewing  this  type  and  volume  of  data  by  1993. 

E.      SUMMARY  OF  FINDINGS 

1.  EC  and  Different  Solicitation  Methods 

Current  EDI  processing  could  support  IFB  for  sealed  bids  because 
each  item  in  the  IFB  has  precise  terms;  part  number,  quantity,  ship-to 
address,  etc.,  but  the  ROI  would  be  small  because  of  relatively  low  volume  of 
IFBs,  according  to  Drake  (1991).  EC  support  for  RFPs  for  competitive  proposals 
are  currently  difficult  because  of  the  large  volumes  of  text,  technical  data,  and 
the  lack  of  an  architecture  for  multimedia  data  interchange  required  for  video 
teleconferencing.  BOA  sole  source  orders  and  indefinite  delivery  contract  orders 
could  receive  the  best  support  from  current  EC  and  are  very  high  volume 
(Drake,  1991). 

2.  OSI  Standards  Are  the  Solution 

a.     OSI 

OSI  will  make  EC  with  large  complex  documents  consisting  of 
text,  engineering  specifications  and  drawing  possible  without  regard  to  the 
platform  and  allow  multimedia  and  hypermedia  data  interchange.  CALS  is 
developing  data  interchange  formats  and  networks  to  exchange  complex 
documents.  Use  of  X.400  now  will  force  compliance  with  OSI  and  provide 
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global  interconnectivity  and  not  just  connectivity  to  US  firms.  Addresses  in  the 
X.500  directory  would  work  with  other  OSI  standards. 

b.     FTAMIFTP  Gateway 

FT  AM  (ISO  8571)  is  another  published  standard  used  by  a  few 
VANs  and  carriers  to  transfer  files.  It  is  an  alternative  to  X.400  which  is  often 
the  vehicle  of  choice  for  EDI,  but  in  certain  regions  there  is  a  tendency  to  use 
FTAM.  For  example,  French  banks  chose  to  use  FTAM  for  a  major  system 
because  of  electronic  security  issues  in  Europe.  DOD  uses  FTP  as  standard  for 
file  transfer.  An  FT  AM/FTP  gateway  would  provide  OSI  compatibility  to  DOD 
at  layer  seven  but  this  would  require  considerable  overhead  according  to 
Henshall  (1989). 

3.     Digital  Signatures 

Statutes  and  laws  need  to  be  revised  to  make  the  use  of  digital 
signatures  acceptable  in  court  should  the  need  arise.  NIST  has  adopted  ANSI 
X9.9  to  provide  an  effective  means  to  authenticate  the  integrity  of  messages 
(InfoSec  Conference,  1991).  Operating  systems,  databases,  application  software, 
and  access  control  software  do  not  provide  adequate  data  integrity  to  stand  up 
in  court.  Crytographic  authentication  such  as  PKE  is  needed  for  most 
applications. 


43 


4.  Electronic  Contracting 

Users  could  negotiate  contracts  through  the  use  of  E-Mail  by 
providing  queries,  messages,  and  discussions  with  archiving  or  electronic  file 
cabinet.  ASC  X12  841  Specification/Technical  Information  transaction  set 
combines  graphics  and  text  into  a  compound  document.  CCITT  X.435  standard 
is  designed  for  EDI  using  the  X.400  Message  Handling  System.  EDI 
transactions  would  be  placed  in  an  E-mail  envelope  to  move  large  files. 
Reliance  on  DDN  will  place  DOD  further  behind  than  it  is  now  with  its 
proprietary  protocols.  With  the  end  of  the  Cold  War,  the  role  of  DOD  may 
shrink  rapidly  while  the  role  of  businesses  will  increase  logarithmically. 
Vendors  will  have  a  difficult  time  trying  to  access  DOD  information  if  it 
remains  in  the  DDN  environment.  It  will  be  hard  for  the  commerical 
community  to  interface  with  DOD  if  the  IGP  is  not  fielded  until  1994  because 
industry  is  well  on  the  way  to  OSI.  X.400  is  projected  for  beta  testing  by  early 
1992.  DOD  cannot  afford  to  wait  until  1994  for  development  of  the  DOD 
Intelligent  Gateway  Processor  (IGP).  Commercial  equivalents  of  the  IGP  exist 
today  and  should  be  used  instead  of  developing  an  IGP  in-house. 

5.  Re-engineering 

DOD  should  re-engineer  workflows  before  implementing  EDI  into 
existing  systems,  according  to  Strassman  (1991).  If  DOD  simply  substitutes  an 
electronic  transaction  for  a  paper  one  or  a  phone  call,  then  EDI  may  cost  the 
Government  more  than  it  does  now  in  an  automated  paper  based  environment. 
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IV.  OSI  OPEN  SYSTEMS  INTERCONNECTION 

A.      BACKGROUND 

1.      Older  Networks 

Some  networks  are  interconnected  physically  but  not  designed  to 
allow  transparent  exchange  of  data.  Only  basic  physical  connectivity  between 
points  existed  a  few  years  ago.  Many  examples  of  floppies  being  mailed  around 
the  country  or  world  still  exist  today.  The  size  of  the  floppy  has  changed  and 
the  amount  of  data  on  the  floppy  increased,  but  the  fact  that  the  mail 
transports  the  data  remains.  According  to  the  CALS  Implementation  Plan 
(1987),  DOD  suggests  keeping  this  modus  operandi  in  place  and  not  to  fully 
pursue  the  electronic  solution  to  transport  multimedia  and  hypermedia  data 
until  after  1995.  At  that  time,  according  to  the  Defense  Message  System  Plan 
(1991),,  the  messaging  part  of  DDN  will  be  replaced  by  a  much  more  robust 
system  based  on  OSI  standards. 

Even  though  two  platforms  may  be  wired  together,  the  same 
communications  protocol  must  be  used  to  transmit  data  to  each  other.  The 
growth  of  LANs  in  the  late  1980s  caused  the  need  for  interconnectivity  of 
workgroups  in  the  matrix  organizations.  Businesses  and  the  DOD  changed  the 
way  they  do  business  from  heirarchial  organizations  to  matrix  organizations 
which  provide  support  horizontally  rather  than  duplicate  themselves  vertically. 
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Even  if  these  matrix  departments  added  PCs,  LANs,  or  mini-computers  they 
still  may  require  connectivity  to  a  central  computing  center  and  to  each  other. 
In  a  geographically  distributed  network  it  may  be  difficult  to  funnel  data 
through  the  central  computer  because  of  the  amount  and  volume  of  traffic. 

2.     Open  Systems  Networks 

Open  systems  networks  are  not  only  interconnected  physically  but 
also  allow  transparent  exchange  of  data  throughout  the  world.  The  primary 
goal  of  OSI  is  to  provide  interoperability  between  computers  in  different 
countries  and  corporations  using  a  common  communications  infrastructure. 
OSI  is  a  set  of  standards  published  by  ISO  and  CCITT  for  data 
communications.  Henshall  (1989)  discusses  the  ISO  seven  layer  reference 
model.  Multi-platform  and  multi-vendor  environments  in  which  all  machines 
interoperate  globally  is  the  goal  of  OSI. 

Interoperable  platforms  can  exchange  data  through  a  distributed 
application.  For  example,  a  user  could  send  an  E-mail  message  to  a  user  on 
another  network  through  a  gateway.  A  client-server  relationship  allows 
cooperation  among  several  connected  computers.  A  user  could  access  a 
distributed  database  or  groupware.  Groupware  includes  spreadsheeting, 
electronic  meetings,  multimedia  messaging  and  compound  documents, 
workflow  automation,  and  mail-enabled  applications. 

The  movement  to  open  systems  began  with  proprietary  protocols  of 
single  vendors  such  as  IBM,  DEC,  Xerox,  and  HP.  Next  the  DOD  pioneered  the 
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TCP/IP  protocol  suite.  Multi-vendor  support  of  TCP/IP  produced  the  ability  to 
send  E-mail  between  different  organizations  by  installing  the  TCP/IP  software 
on  routers.  The  E-mail  standard  for  TCP/IP  is  SMTP  which  is  very  basic  and 
lacks  sophisticated  transfer  capability  according  to  Delaura  (1987). 

B.      OSI  REQUIREMENTS 

Many  capabilities  of  OSI  may  require  the  use  of  an  intelligent  gateway 
which  could  exist  on  many  different  platforms.  These  capabilities  include:  1) 
a  layered  peer-to-peer  architecture  with  service  infrastructures;  2)  client-server 
applications  using  virtual  resources;  3)  multi-vendor  and  multi-platform;  and 
4)  being  adaptable  and  seamless.  Distributed  networks  may  need  intelligent 
gateways  which  have  network  control  engines  to  manage  the  network.  One  of 
the  main  intents  of  OSI  is  to  have  different  operating  systems  like  DOS, 
Windows,  OS/2,  Macintosh,  and  Unix  systems  able  to  perform  similar  services 
with  each  other.  The  applications  running  on  the  different  platforms  should  be 
integrated  seamlessly.  This  research  concentrates  on  the  Message  Handling 
System  and  its  capability  to  support  multimedia  multi -platforms  with  text, 
facsimile,  full  motion  video,  and  graphics.  OSI  should  have  the  ability  to  grow 
to  several  million  users  in  thousands  of  locations  around  the  world.  The 
Federal  Government  developed  a  subset  of  ISO  standards  selected  by  NIST  to 
meet  the  needs  of  the  government  agencies  called  GOSIP. 
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C.      OSI  STANDARDS  FOR  MESSAGE  HANDLING  SYSTEM  AND 
DIRECTORY  SERVICES 

1.     X.400  1984  and  1988 

a.  Upper  Layer  Functions 

The  application  layer  at  the  top  of  the  OSI  reference  model  in 
Henshall  (1989)  realizes  the  goal  of  OSI.  The  lower  layers  simply  exist  to 
provide  support  for  the  application  layer.  It  makes  services  available  to 
computer  system  users.  The  main  functions  of  the  seventh  layer  are  file 
transfer  access  management  and  file  directory  operations;  message  handling; 
virtual  terminal  protocol;  and  job  transfer,  manipulation  and  remote  job 
management  (Henshall,  1989). 

b.  X.400  Development 

Development  of  X.400  began  in  1980  with  the  formation  of  the 
CCITT  X.400  Protocol  Committee.  It  took  four  years  to  complete  the  initial 
standards  which  were  released  in  1984  and  as  part  of  the  Red  Book.  The  first 
commercial  products  conforming  to  X.400  of  1984  appeared  in  1986.  According 
to  Scott  (1990),  the  initial  products  were  primarily  OEM  source  code.  The 
committee  produced  a  later  version  of  the  standards  in  1988  which 
incorporated  the  message  store,  multimedia  messaging,  and  security.  Most 
X.400  1988  package  products  were  released  in  early  1990. 
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c.  1984  Standards 

The  1984  standards  included  many  basic  features.  According  to 
Gifkins  (1988),  this  version  only  met  approximately  50  percent  of  the 
requirements  in  Logica's  Report  to  Vanguard  on  EDI  and  X.400.  The  basic 
features  are: 

Delivery  notifications 
Message  tracing 
Integrated  messaging 
Secure  session  establishment 
Binary  and  encrypted  data 
Multi-destination  delivery 
Uniform,  global  addressing 
Distribution  lists 
Grades  of  service 
Deferred  delivery 

d.  1988  Standards 

The  1988  standards  added  two  additional  features  and 
introduced  the  concept  of  a  message  store  which  will  be  discussed  later  in  this 
chapter  (CCITT  X.400,  1988).  According  to  Gifkins  (1988),  this  version  met 
approximately  70  percent  of  the  requirements  in  Logica's  Report  to  Vanguard 
on  EDI  and  X.400.  The  two  added  features  are: 
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•  Generic  advanced  security 

•  Latest  delivery  time 

e.     X.400  Model 

The  X.400  model  contains  user  agents  and  message  transfer 
service.  The  user  agent  defines  the  contents  of  the  message  which  can  be  sent. 
The  1984  version  was  designed  to  send  several  different  types  of  messages  but 
only  one  type  called  interpersonal  message  (IPM)  is  specified  in  the  1984 
standard.  IPM  resembles  a  regular  office  memo  (i.e.,  To:,  From:,  CC:,  Subject:, 
Priority:,  In  reply  to:,  text,  drawings,  graphics,  and  voice)  and  is  generally 
defined  by  the  P2  protocol.  P2  defines  a  header  and  a  body.  The  header 
consists  of  addressing  information.  The  body  consists  of  one  or  more  body  parts 
which  each  have  specific  formats.  The  message  transfer  agent  determines  how 
to  route  messages  from  sender  to  receiver.  The  MTA  provides  for  store  and 
forward  service  as  defined  by  the  PI  protocol.  More  than  one  user  agent  can 
use  the  services  of  a  single  message  transfer  agent.  The  MTA  routes  messages 
to  the  destination  and  delivers  for  their  local  user  agents.  MTA  addressing 
uses  a  facility  called  originator/receiver  name  which  is  designed  to  provide  all 
the  necessary  information  to  send  a  message  internationally. 
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2.     X.435  PEDI 

a.  Development 

The  CCITT  recognized  that  EDI  would  require  a  basis  for  storing 
and  forwarding  messages  around  the  world  with  grades  of  service  and  support 
of  binary  message  contents.  The  committee  therefore  began  development  of 
X.435  in  early  1988.  Until  1988,  EDI  and  X.400  standards  pursued  separate 
development.  CCITT  recently  approved  the  1990  X.435  standard  in  June  1991 
and,  according  to  Eckerson  (1991),  industry  analysts  predict  that  the  1990 
standard  will  not  be  implemented  until  1993.  Vendors  are  in  the  process  of 
implementing  agreements  on  how  to  implement  X.435  and  should  complete  the 
agreements  by  the  end  of  1991.  Eckerson  (1991)  states  that  it  will  take  6-9 
months  to  create  beta  versions  to  field  in  late  1992.  Meanwhile,  the  DOD  will 
be  pursuing  EDI  over  DDN  through  an  intelligent  gateway  which  is  not 
scheduled  for  implementation  until  1994  as  stated  in  DLA  (June,  1990). 
According  to  Sweeney  (1991),  the  DOD  does  not  plan  to  include  X.400  in 
GOSIP  until  1994. 

b.  Features  Added  in  the  1990  X.435  Standards 

(1)  Advanced  security  specifically  for  EDI.  Each  part  of  the 
path  of  an  EDI  message  can  be  protected  by  using  encryption  of  data, 
verification  of  message  sequence  integrity,  authentication  of  message  originator 
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and  receiver,  non-repudiation,  and  authentication  of  the  delivered  message 
contents  according  to  the  CCITT  X.435  (1991). 

(2)  Message  body  parts.  X.435  defines  EDI  messages  to  have 
at  least  one  body  part  which  is  a  place  within  the  message  where  EDI 
interchange  is  carried.  The  first  body  part  is  always  the  part  that  contains  EDI 
data.  Subsequent  body  parts  may  carry  different  types  of  data  (Figure  2).  A 
CAD/CAM  drawing,  1840A  engineering  graphic,  PDES,  or  just  text  related  to 
the  EDI  data  could  be  contained  in  the  other  body  parts.  The  alternative 
approach  is  similar  to  the  CALS  data  in  an  841  transaction  proposed  by 
Saltman  (1990).  It  is  more  difficult  for  the  communication  software  to  perform 
the  CAD/CAM  processing  because  the  X12  overhead  data  must  be  stripped 
away  first  before  the  binary  data  can  be  processed. 

(3)  Cross-referencing  table.  The  X.435  EDI  message  has  a  table 
which  may  allow  several  CAD/CAM  drawings  to  be  linked  to  a  separate  body 
part  which  contains  the  EDI  interchange.  Each  page  of  the  interchange  may 
reference  one  of  several  CAD/CAM  drawings  using  the  table. 

(4)  Forwarding  of  EDI  messages  and  EDI  responsibility.  A  user 
may  request  notification  on  whether  the  recipient's  software  accepted,  refused, 
or  forwarded  the  message  he  sent.  The  issuance  of  the  notification  report  is  a 
function  of  the  UA.  With  this  action,  the  software  takes  responsibility  for  the 
message  and  informs  the  users  of  who  has  responsibility  at  any  specific  time. 
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Figure  2.  X.435  PEDI  Message  Structure. 
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If  the  user  has  a  central  X.400  gateway  through  which  all  messages  are 
screened  and  audited,  the  X.435  software  examines  the  message  and 
determines  if  it  will  be  able  to  pass  the  message  to  the  recipient's  application. 
A  user  from  Japan  may  send  an  EDIFACT  message  to  DOD  which  uses  X12. 
The  X.435  software  then  determines  that  the  formats  are  incompatible  and  if 
the  gateway  does  not  contain  multiple  protocol  converters  will  refuse  to  take 
EDI  responsibility  for  the  EDIFACT  message  and  return  a  negative 
notification  to  the  sender  if  requested. 

(5)  EDI  notifications.  Three  types  of  EDI  notifications  provide 
extra  tracking  capabilities  beyond  the  simple  notification  of  delivery.  First,  a 
positive  EDI  notification  lets  the  sender  know  that  the  software  accepted  EDI 
responsibility  for  the  message  after  examining  it  and  determining  that  the 
interchange  can  be  processed  by  the  recipient's  application.  Second,  a  negative 
EDI  notification  lets  the  sender  know  that  the  software  refused  EDI 
responsibility  for  the  message  after  examining  it  and  determining  that  the 
interchange  cannot  be  processed  by  the  recipient's  application.  The  third  is  a 
forwarding  notification  that  tells  the  sender  that  the  message  was  forwarded 
along  with  the  EDI  responsibility  to  another  user. 

(6)  Message  store.  The  combination  of  database  functions  such 
as  queries,  retrievals,  deletions,  searches,  and  sorts  of  a  mailbox  allow  users 
to  have  the  full  functionality  of  an  X.400  VAN  or  network  without  the 
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overhead  of  having  to  completely  implement  X.400  or  X.435  on  their  computer. 
The  message  store  assists  the  smaller  EDI  users  because  they  do  not  have  the 
computing  resources  or  financial  resources  to  fully  implement  X.435.  Incoming 
messages  would  be  placed  into  the  user's  message  store.  When  the  user  logs 
on,  they  can  be  alerted  about  new  messages  or  other  optional  criteria  that  was 
selected.  Other  messages  may  also  be  retrieved  from  the  mailbox  according  to 
these  criterion.  For  example,  the  U.S.  Army  Tank  Command  may  want  to  look 
at  just  EDI  messages  from  General  Motors  for  the  month  of  July  1991  that 
contain  invoicing  information. 

3.     X.500  Directory  Service  (ISO  9594  or  CCITT  X.500) 

Since  the  growth  of  networking  started,  there  has  been  an  increasing 
demand  to  maintain  information  about  what  kind  of  computers  are  on  the 
network.  The  information  includes  application  programs,  people  using  the 
computer,  and  a  physical  address.  E-mail  directories  provide  look  up  services. 
DDN  provides  a  Unix  like  command  "Whois"  to  give  directory  type  information 
on  individuals  using  DDN.  However,  the  DDN  Network  Information  Center 
can  only  provide  this  information  for  DDN  hosts  only.  Similar  to  most 
proprietary  networks,  these  applications  cannot  be  used  on  interconnected 
heterogenous  networks.  For  example,  AT&T  Starmail  and  MCI  Mail  are 
interconnected  and  a  user  from  one  system  may  send  mail  to  a  user  on  the 
other  system  if  he  knows  the  address.  However,  if  the  address  is  unknown,  a 


55 


Starmail  user  cannot  check  for  an  MCI  E-mail  address  or  vice  versa  and  the 
Starmail  user  cannot  send  the  E-mail  to  the  MCI  user. 

There  is  a  great  need  for  a  globally  interconnected  directory  which 
provides  links  to  individuals,  distribution  lists,  MTAs,  application  entities,  and 
all  UAs.  Either  the  directory  name  or  the  originator/recepient  address  must  be 
contained  in  the  user's  message.  The  directory  name  will  be  more  user  friendly 
than  the  address  which  may  change  because  of  the  physical  configuration  of 
the  Message  Handling  System.  A  message  with  just  a  directory  name  will 
cause  the  Message  Handling  System  to  consult  the  directory  to  find  the 
corresponding  address.  If  the  message  contains  the  address,  the  Message 
Handling  System  will  use  the  address  provided  to  route  the  message.  A  user 
can  use  the  directory  service  to  verify  a  given  address  or  find  out  additional 
information  about  a  specific  user.  The  address  is  an  ordered  list  of  attributes. 
It  can  be  private  or  administration  domain  defined,  a  personal  name, 
distribution  list  name,  organizational  unit  name,  and  mneumonic  addresses 
and  called  relative  distinguished  name. 

X.500  allows  user  friendly  naming  of  objects  and  name-to-address 
mapping  which  supports  the  binding  of  objects  and  their  locations.  The 
directory  is  a  specialized  database  supporting  management  and 
telecommunication  processes  in  a  standardized  format  jointly  developed  by  ISO 
and  CCITT.  The  directory  will  be  logically  one  directory  but  physically 
distributed  with  a  unified  name  space.  Directory  user  agents  and  system 


56 


agents  will  provide  the  application  or  human  user  with  the  ability  to  query  the 
directory  information  database.  This  is  done  by  using  the  directory  access 
protocol  between  user  agents  and  directory  system  protocol  between  system 
agents. 

4.      Defense  Message  System  (Program  Plan) 

DOD  tried  to  satisfy  all  messaging  requirements  in  a  single  system 
procurement  with  the  InterService/Agency  Automated  Message  Processing 
Exchange  (AMPE)  in  1987.  Do  to  severe  budget  constraints,  a  rapidly  changing 
technology  and  new  international  standards,  AMPE  was  cancelled  and  replaced 
with  an  evolutionary  process  to  modernize  the  messaging  system.  AUTODIN 
and  DDN  form  the  baseline  and  will  be  replaced  by  off-the-shelf  products 
conforming  to  international  standards  forming  a  distributed  messaging  system 
based  upon  X.400  and  X.500.  Phase  1  ends  in  1994  and  includes  transitioning 
from  TCP/IP  to  TP4  and  from  SMTP  to  X.400.  AUTODIN  traffic  will  switch  to 
DDN  and  by  the  end  of  Phase  Two,  all  Telecommunication  Centers  will  begin 
phasing  out.  (Draft  Defense  Message  System  Plan,  1991) 

D.     ANALYSIS 

1.      Defense  Message  System 

An  X.400  based  solution  is  proposed  in  the  Defense  Message  System 
Program  Plan  for  DOD  communication  requirements.  The  schedules  for  this 
transition  all  indicate  that  the  X.400  conversion  will  start  in  late  1991  for  some 
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services  and  be  completed  by  mid  1992.  Based  upon  commericially  available 
packages,  this  conversion  will  implement  1988  X.400  standards.  However, 
when  the  1990  X.435  standards  become  commercially  available,  it  should  be 
easy  to  upgrade  because  customers  will  have  had  experience  with  X.400 
products. 

Several  corporations  have  developed  platforms  capable  of  performing 
at  least  the  same  requirements  as  the  Lawrence  Livermore  National 
Laboratories  Intelligent  Gateway  Processor.  Off-the-shelf  EDI  translation 
software  allows  parameter  changes  which  could  accomodate  DOD  fields  for 
processing.  If  DOD  simply  wants  to  automate  existing  processes  then  it  would 
be  extremely  cost  efficient  to  purchase  a  specific  software  package  which  is 
multi-platform  capable  on  a  PC.  However,  DOD  should  completely  rethink  how 
it  performs  its  processes  before  implementing  any  EDI  applications  over  X.435. 
Automating  what  a  paper  based  system  performs  should  be  done  after  an 
analysis  of  how  to  electronically  perform  the  work  by  rethinking  the  process. 

2.     X.435  Versus  Non-X.400 

There  are  several  advantages  of  using  X.435  versus  non-  X.400  based 
EDI  according  to  Lyons  (1991).  First,  X.400  allows  audit  trails  to  track  each 
message  through  delivery  notification  and  message  tracing.  The  two  types  of 
delivery  notifications  are:  1)  positive  which  tells  whether  the  message  was 
placed  in  the  receiver's  mailbox  successfully  or  2)  negative  which  also  tells  why 
the  message  could  not  be  delivered.  X.400  users  can  even  find  out  if  a  message 
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was  delivered  to  a  receiver  on  a  different  network  because  the  last  X.400 
network  generates  the  delivery  notification.  Each  envelope  documents  the  path 
that  the  message  takes  from  the  sender  to  the  receiver.  Each  time  the  message 
transfers  between  X.400  networks,  the  envelope  is  updated  with  the  name  of 
the  X.400  network  through  which  it  is  passing. 

Second,  EDI  and  E-mail  may  be  integrated  on  one  network  instead 
of  two  because  X.400  provides  both  services  in  the  same  protocol.  A  trading 
partner  may  use  a  VAN  if  he  does  not  have  X.400  capability.  X.400  can  even 
be  used  to  send  and  receive  facsimile  messages. 

Third,  since  X.400  is  an  international  standard,  it  is  just  as  easy  to 
send  an  E-mail  message  to  a  foreign  receiver  as  it  is  to  call  them  because  most 
X.400  networks  are  international  or  interconnect  to  other  foreign  X.400 
networks.  More  and  more  EDI  users  who  are  part  of  a  global  enterprise  are 
moving  to  X.400. 

Fourth,  one  security  feature  of  X.400  establishes  a  secure  session  and 
the  other  allows  the  envelope  to  encrypt  EDI  data.  Secure  session 
establishment  uses  a  logon  ID  and  a  password.  Since  binary  data  can  be 
carried,  users  can  transmit  encrypted  data  which  prevents  the  sender  or 
receiver  from  reading  that  data.  CAD/CAM  data,  spreadsheet  files,  faxed 
images  also  require  binary  data  and  can  be  encrypted. 

Fifth,  like  most  E-mail  systems  X.400  allows  a  single  message  to  go 
to  multiple  recipients  with  the  use  of  distribution  lists.  These  addresses  are 
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unique  in  the  entire  world  because  they  include  user's  name,  company,  X.400 
VAN,  and  country.  Neither  EDIFACT  nor  X12  use  a  uniform  global  addressing 
scheme.  The  distribution  list  is  created  only  once. 

Finally,  unlike  most  E-mail  systems  X.400  offers  three  grades  of 
service  which  determine  how  quickly  a  message  is  delivered  and  the  cost  of 
delivering  the  message.  Many  types  of  junk  mail  could  be  sent  non-urgent. 
Some  invoices  or  purchase  orders  may  be  sent  normally  and  mistakes  in 
payment  may  be  sent  urgently.  A  user  can  even  set  up  a  specified  date  and 
time  of  delivery  several  weeks  into  the  future. 

E.      SUMMARY 

Since  X.400  can  distinguish  between  the  envelope  and  its  contents,  it  is 
well  suited  for  store-and-forward  messaging  such  as  EFT  and  EC/EDI. 

Since  X.400  can  support  all  earlier  technologies  such  as  E-mail,  telex, 
facsimile,  and  exchange  binary  formatted  data  it  is  also  well  suited  for  CALS 
and  other  technical  data  interchange  requirements. 

Commercially  available  software  implementing  the  1988  X.400  standards 
is  available  for  intelligent  gateways.  These  software  packages  could  be  used  to 
handle  most  CALS  requirements.  Software  implementing  the  1990  X.435 
standards  will  be  commercially  available  in  less  than  one  year.  It  could 
potentially  benefit  DOD  to  rapidly  re-engineer  processes.  After  completion  of 
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the  re-engineering  new  products  could  be  available  that  will  support 
multimedia  and  hypermedia  interchange  required  in  CALS  and  EC/EDI. 

A  second  option  available  to  DOD  is  to  use  a  VAN  which  will  have  the 
1990  standard  implemented  in  mid  1992.  Linking  to  a  VAN  which  provides  all 
the  required  services  may  be  more  economic.  VANs  have  intelligent  gateways 
and  could  be  used  as  soon  as  parameters  became  established  by  DOD. 

With  the  adoption  of  X.435  in  June  1991  as  an  international  standard,  the 
Message  Handling  System  will  become  even  more  necessary  to  EDI  and  CALS 
users  and  should  become  the  global  standard  for  EDI  messaging  as  more  X.435 
products  become  available.  According  to  Scott  (1990),  research  indicates  that 
the  market  for  X.400  based  gateways  will  grow  by  60  percent  over  the  next 
three  years,  reaching  close  to  $100  million  by  1993.  Vendors  that  want  to  sell 
to  a  global  market  see  X.400  as  a  platform  with  worldwide  appeal.  In  1992, 
after  the  European  trade  barriers  will  be  lifted,  open  system  standards  will 
greatly  increase  trade  in  Europe. 
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V.  MULTIMEDIA  AND  HYPERMEDIA  DATA 
INTERCHANGE  ARCHITECTURE 


A.   BACKGROUND 

The  evolution  of  multimedia  data  involved  three  types  of  documents:  1) 
dumb  documents;  2)  compound  documents;  and  3)  intelligent  documents.  The 
dumb  document  exists  on  only  one  type  of  media  and  must  be  manipulated  in 
its  entirety.  The  compound  document  combines  different  types  of  media  and 
may  be  flexibly  distributed  and  assembled.  The  intelligent  document  functions 
as  a  hypermedia  system  supported  by  expert  systems  to  solve  problems  and  to 
enhance  user  performance. 

1.      Dumb  Documents 

The  dumb  document  can  also  be  called  the  paper  based  document.  It 
can  be  either  in  traditional  hard  copy  conforming  to  standard  formats  or  data 
item  descriptions  in  a  contract.  The  dumb  document  can  be  mailed  through  the 
postal  system,  Federal  Expressed,  etc.,  but  always  exists  on  permanent  paper. 
Before  the  next  step  in  the  evolution  of  multimedia,  technology  developed  to 
make  images  of  the  dumb  document.  Data  processors  became  obsessed  with 
image  processing  and  the  need  to  access  archived  documents.  The  microfiche 
technology  used  for  over  the  past  20  years  is  gradually  being  replaced  by 
optical  storage  technology.  Large  documents  which  are  complex  may  be  stored 
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more  easily  on  an  optical  disk  which  may  then  be  mailed.  These  large 
documents  require  lengthy  transmission  times  across  networks  and  in  today's 
networking  environments  have  great  difficulty  traversing  through  gateways. 
Point  to  point  transmissions  may  take  hours  depending  on  the  length  and 
complexity  of  the  document.  However,  for  relatively  short  page  based 
documents,  Group  4  raster  graphics  allow  the  use  of  telecommunications  to 
make  a  facsimile  of  the  document  and  send  it  electronically  to  another 
facsimile  machine  either  from  a  stand  alone  computer  or  from  a  network 
facsimile  server,  or  a  stand  alone  fax  which  prints  out  a  paper  document. 

2.      Compound  Documents 

The  compound  document  consists  of  data  components  of  different 
types  which  a  computer  may  process  individually.  Electronic  scanners  have 
added  the  dimension  of  converting  handwritten  text  to  word  processed  text. 
The  word  processing  of  text  files  began  the  evolution  to  hypertext.  Standards 
such  as  SGML  are  in  the  process  of  evolving  to  guide  the  integration  of 
multimedia  with  text  to  form  compound  documents.  Plain  text  documents  are 
rapidly  becoming  obsolete.  Graphics  files  have  several  standards  depending  on 
the  type  of  graphic  used.  CGM,  IGES,  and  raster  graphics  discussed  in 
Chapter  II  form  the  basis  for  the  graphic  metafiles  required  for  compound 
documents.  Database  queries  using  SQL  present  views  of  objects.  Audio/visual 
files  are  part  of  multimedia  kits  and  business  presentations  in  forms  of 
animation,  3D,  photos,  combined  with  graphics  and  text.  These  integrated  files 
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pose  the  biggest  challenge  to  interchanging  data  in  electronic  commerce  and 
CALS/CE. 

3.     Intelligent  Documents 

The  intelligent  type  of  document  is  a  virtual  document.  It  does  not 
really  exist.  There  is  no  need  for  archiving  just  for  the  information  provided  by 
virtual  document.  Certain  applications  may  have  predefined  queries  to 
multimedia  databases  which  the  virtual  document  may  execute  to  obtain 
certain  data  from  other  multimedia  databases.  Other  applications  allow  ad  hoc 
queries  to  the  multimedia  databases.  For  example,  an  expert  system  conducts 
a  hypersearch  of  several  multimedia  databases  after  a  user  asks  a  speech 
recognition  neural  network  which  in  turn  consults  the  expert  system  for 
information.  Accessing  hypermedia  across  networks  will  be  difficult  with  low 
speed  lines.  Current  solutions  indicate  that  the  hypermedia  be  physically 
transmitted  through  the  mail  or,  if  small  enough,  transmitted  electronically  as 
a  binary  file.  X.400  allows  the  different  data  types  to  cross  networks. 
Hypersearches  of  multimedia  databases  located  in  different  networks  will 
require  high  speed  lines  and  X.400.  After  the  system  or  user  finishes  with  the 
information  created  by  the  hypersearch  they  can  produce  a  new  hypermedia 
document  and  store  it  by  creating  a  virtual  intelligent  document  that  knows 
where  to  locate  the  information  the  next  time  it  is  needed. 
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B.      REQUIREMENTS 

1.  Hypermedia 

Hypermedia  incorporates  many  complex  information  types  that  may 
exist  on  multiple  platforms  across  a  network.  They  are  semantically 
interdependent  and  synchronized.  Hypermedia  allows  cross-reference  of  all 
relevant  works  and  lets  the  user  browse  to  look  for  other  relationships.  They 
may  contain  full-motion  including  video  and  voice  annotations.  Thus, 
hypermedia  interchange  will  require  high  resolution  displays,  high  volume 
mass  storage,  and  high  speed  data  communications.  No  one  specific  document 
contains  what  the  person  wants  but,  after  learning  and  getting  new  ideas  from 
browsing  around  they  may  find  what  they  want.  Few  corporations  can  afford 
hypermedia  interchange  at  this  level  and  must  settle  for  much  less.  Currently, 
it  is  possible  to  send  different  types  of  information  in  one  message  using  X.400 
but  there  are  practical  limits  to  the  size  of  the  files,  according  to  Asgher  (1991). 

2.  Intelligent/Compound  Documents 

Desktop  publishing  of  forms  represents  over  a  third  of  all  business 
documents,  accounting  for  $6  billion  and  wasting  nearly  $2  billion  of  it, 
according  to  Skapinker  (1991).  Distribution,  storage,  and  processing  account 
for  $100  billion  because  for  every  $1  spent  on  paper,  it  costs  $60  to  process  it 
(Skapinker,  1991).  Even  though  the  forms  are  created,  distributed,  and  filled 
electronically,  businesses  usually  need  a  desktop  publishing  capability.  There 
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is  usually  a  need  for  signatures  particularly  in  DOD.  By  signing  the  paper 
form,  the  form  fillers  take  responsibility  for  the  contents  of  the  form.  Once  the 
form  is  filled  out,  the  inputted  data  needs  to  be  stored  and  the  form  used 
again.  The  forms  must  be  indexed  because  these  forms  or  images  are  dumb 
without  tagging  them  with  additional  and  searchable  information. 

Compressing  and  decomposing  large  complex  documents  helps  with 
routing  but  each  end  user  must  construct  and  reconstruct  the  images  in  a 
compatible  way.  If  the  users  are  on  networks  and  are  a  part  of  a  larger 
organization,  its  impact  on  the  network  is  very  significant.  In  fact,  optical  disk 
storage  called  jukeboxes  are  often  used  to  handle  the  massive  amounts  of 
storage  required.  Unfortunately,  jukeboxes,  laser  printers,  faxes,  scanners,  and 
electronic  tablets  greatly  clog  up  any  current  network  which  forces  a  reduction 
in  the  user/server  ratio.  OSI  is  attempting  to  define  standards  for  the  future 
business  office  to  gain  control  of  all  the  merging  technologies  in  the  intelligent 
document. 

3.      Electronic  Document  Staffing 

Groupware  allows  computer-supported  cooperative  work  whether 
people  are  seated  next  to  each  other  or  in  different  countries.  For  example, 
when  the  Army  Combat  Developers  field  a  new  piece  of  equipment,  they  may 
need  software  that  manages  the  component  parts  of  the  big  single  document 
that  comes  from  26  different  sites  around  the  country.  This  software  should 
allow  one  member  to  make  comments  on  another's  document.  The  author  could 
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review  the  comments  and  either  accept  or  reject  them  before  forwarding  them 
to  an  approving  authority  for  review  and  signature. 

4.      Electronic  File  Cabinet 

Distributed  multimedia  database  may  involve  many  forms  of 
information  located  in  many  locations.  For  example,  offices  and  organizations 
keep  standard  file  drawers,  desk  files,  notes,  reminders,  cassette  tapes,  copies 
of  faxes,  pictures,  videos,  microfiche,  compact  discs,  floppy  disks,  and  even 
removeable  hard  drives. 

Cost  estimates  for  manually  filling  a  five  drawer  file  cabinet, 
assuming  $5  per  piece  of  paper,  range  up  to  $50.00  per  drawer  of  1000  sheets. 
Maintaining  that  drawer  could  cost  approximately  10%  or  $5.00  per  year.  The 
worst  part  is  that  approximately  5%  or  50  documents  will  become  misfiled  and 
thus  lost  unless  a  complete  search  of  each  file  is  done  at  great  time  and 
expense  which  may  double  the  cost  of  the  piece  of  paper  to  $10  or  more.  The 
manager  waiting  for  the  misplaced  documents  may  lose  large  contracts  or 
potential  profits. 

One  cabinet  may  hold  up  to  a  tenth  of  a  gigabit  of  data  assuming 
that  the  average  document  size  is  50  kilobits  per  page.  Hard  disks  alone 
cannot  handle  this  requirement  but  may  be  used  in  conjunction  with  optical 
technologies  for  indexing  and  temporarily  retrieving  working  documents  from 
the  optical  disk.  WORM  media  automates  and  centralizes  annotations, 
histories  of  the  document,  and  proposed  revisions  to  the  document.  Current 
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technology  allows  the  creation  of  virtual  WORM  on  a  rewriteable  drive. 
However,  only  a  copy  of  a  document  on  a  WORM  drive  is  considered  a  legal 
copy.  Passing  this  information  currently  is  done  by  the  sneakernet.  A  good 
candidate  for  multimedia  data  interchange  would  be  exchanging  massive 
amounts  of  data  over  fiberoptic  infrastructures  such  as  FDDI. 

5.      Document  Imaging 

The  central  technology  for  a  paperless  office  is  document  imaging. 
Paper  documents  are  scanned  into  document  image  files  which  may  be  stored 
on  an  optical  disk  for  retrieval,  viewing,  and  printing.  A  typical  industry  model 
of  a  document  image  management  system  includes  scanning  and  retrieval 
workstations  connected  to  a  laser  printer,  a  document  image  processor  server 
connected  to  a  large  optical  jukebox  and  laser  printer,  workstations  connected 
to  laser  printers,  and  a  link  between  the  corporate  mainframe  and  the 
electronic  archival  system.  A  database  holds  the  current  day's  scanning 
activity.  The  master  database  holds  all  the  documents  in  the  system  after  the 
images  are  scanned,  compressed  by  Group  4  standards  and  sent  to  the  jukebox. 
The  retrieval  of  a  document  allows  keyword  searches,  multiple  document 
displays,  and  the  ability  to  zoom  in  on  a  particular  area. 

One  of  the  best  examples  of  a  paperless  corporation  is  the  United 
Services  Automobile  Association  which  provides  insurance  for  active  duty  and 
retired  officers  of  the  armed  forces  and  their  dependents.  According  to  Harvey 
(1991),  over  1,000  graphics  terminals  connected  to  a  large  IBM  3090  MVS/EVA 
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system  and  separate  dedicated  IBM  4381s  show  the  document,  its  history  log 
and  notes  on  file.  The  terminal  allows  the  viewer  to  turn  pages,  zoom, 
rearrange  pages,  enter  certain  page  numbers,  and  handle  the  document  as 
though  it  was  horizontal  instead  of  3D.  Their  storage  system  consists  of  five 
optical  jukeboxes  and  30  stand-alone  optical  WORM  drives  capable  of 
containing  over  2  terrabytes  of  data.  (Harvey,  1991) 

6.      Electronic  Videoconferencing  and  Teleconferencing 

Sometimes  instead  of  holding  a  meeting  at  one  location,  significant 
traveling  expenses  and  time  can  be  saved  by  reviewing  the  same  documents 
in  real  time  by  holding  a  video  teleconference.  During  a  typical 
videoconference,  paper  documents  are  shown  to  the  camera  and  seen  in 
multiple  locations.  Future  conferences  should  have  the  capabilities  of  having 
the  identical  screen  at  all  locations  with  changes  made  to  any  screen  seen 
simultaneously  on  all  the  terminals.  The  waste  of  time  to  postpone  and 
reconvene  a  conference  for  lack  of  information  that  exists  in  a  different  format 
will  be  eliminated  by  gaining  access  to  databases  with  the  necessary 
information. 

C.      CAN  DATA  COMMUNICATIONS  BE  BASED  ON  DDN? 

Most  DDN  backbone  circuits  between  packet  switch  nodes  are  56  Kilobits 
with  a  few  T-l  lines.  The  access  lines  to  the  terminal  access  controllers  are 
normally  9,600  bits/second.  DDN  has  limited  connectivity  to  other  networks. 
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For  example,  E-mail  can  be  sent  to  an  SNA  network  through  a  Softswitch 
gateway,  but  at  a  very  slow  rate.  As  discussed  in  Chapter  III,  the  amount  of 
data  sent  over  the  network  will  greatly  increase  with  the  use  of  compound 
documents.  Compression  techniques  exist  but  the  volume  of  messages  and  the 
size  of  graphics  files,  even  when  compressed,  may  be  one  megabit.  Sending  one 
engineering  drawing  could  take  at  least  two  minutes  if  sent  within  DDN  and 
could  take  all  day  if  sent  through  the  gateway  depending  on  the  queue  of  all 
other  messages  trying  to  get  through  the  gateway  to  an  SNA  network. 
Organizations  have  reverted  to  asynchronous  modem  connections  to  transfer 
the  files  point  to  point  when  there  is  a  network  boundary  to  cross.  X.400  will 
eliminate  the  chokepoint  that  exists  when  passing  through  a  gateway  to 
another  network.  If  the  workstation  is  on  a  highspeed  LAN  running  at  10 
Megabits  per  second  and  the  LAN  is  linked  through  an  FDDI  backbone  or 
broadband  backbone  the  throughput  to  another  user  could  conceivably  be  10 
Megabits  per  second  which  would  transmit  the  engineering  drawing  in  less 
than  one  second.  DDN  is  incapable  of  attaining  these  high  speeds.  The  upgrade 
to  the  Bolt,  Baranek,  and  Neuman  processors  only  made  them  capable  of 
handling  more  ports  at  56  Kilobits/second. 
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D.      INTERCHANGE  ARCHITECTURE  FOR  MULTIMEDIA 
AND  HYPERMEDIA  DATA 

1.  EDI  and  X.400  for  Multimedia  Data  Interchange 

In  Chapter  III,  we  discussed  the  requirement  for  including  graphics 
along  with  text  to  form  an  electronic  commerce  transaction.  For  example,  a 
picture  with  a  Request  For  Proposal  would  not  be  be  possible  in  a  conventional 
EDI  transaction  because  a  conventional  EDI  transaction  allows  text  only.  Even 
worse,  not  all  companies  support  EDI  or  are  not  fully  EDI  ready.  It  may  take 
years  to  convert  an  entire  business  and  all  of  its  trading  partners  to  EDI.  Some 
data  may  have  to  exist  in  printable  form  for  human  intervention  because  some 
company  will  still  rely  on  paper  based  systems.  On  the  otherhand,  X.400  can 
accept  facsimile,  E-mail,  IGES,  PDES,  and  other  data  types  to  transmit  to  the 
receiving  partner's  mailbox. 

2.  Hypermedia  and  Multimedia  Interchange  Architecture 

The  telecommunication  infrastructure  for  hypermedia  and 
multimedia  data  interchange  can  best  be  served  by  ISDN  and  FDDI.  The 
Government's  multi-billion  dollar  FTS  2000  contract  supports  ISDN  and  is 
available  for  use  immediately.  On  top  of  this  telecommunications 
infrastructure,  the  OSI  protocol  suite  will  be  used  including  TP4,  FTAM, 
X.400,  X.500,  and  VT  to  form  the  infrastructure  for  the  Defense  Information 
System  which  includes  the  Defense  Messaging  System  discussed  in  Chapter 
III.  The  most  crucial  part  of  the  architecture  (Figure  3)  is  the  multimedia  and 
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hypermedia  data  interchange  standards.  These  standards  include  all  the  ones 
discussed  in  this  thesis,  especially  Chapter  I  for  CALS:  CGM,  SGML,  IGES, 
PDES/STEP,  and  Group  4  Raster;  and  EC/EDI:  EDIFACT,  X12;  and 
ODA/ODIF.  The  applications  to  use  these  standards  include  hypersearch  and 
hypertext,  groupware  DSS,  forms  processing,  multimedia  databases,  hand 
written  character  recognition,  electronic  performance  support  systems, 
electronic  contracting,  document  image  processing,  logistics,  and  neural 
networks.  Public  key  encryption  and  embedded  encryption  along  with  trusted 
databases  and  operating  systems  will  allow  the  existence  of  multi-level  security 
in  this  environment. 

3.      Multi-level  Security  and  Public  Key  Encryption 

a.     Multi-level  Security 

DOD  could  save  a  significant  amount  of  money  if  classified 
documents  could  be  electronically  stored  and  transmitted  between  sites  along 
with  unclassified  documents.  Documents  most  often  are  unclassified  with  the 
exceptionof  one  or  two  pages  which  may  contain  confidential  data,  and  one 
paragraph  of  secret  data  which  makes  the  entire  document  secret.  DOD  has 
spent  billions  of  dollars  maintaining  separate  systems  for  the  unclassified 
environment  and  the  top  secret  and  higher  environment.  Thousands  of 
classified  documents  are  still  manually  controlled  and  locked  in  large  classified 
containers  just  as  they  were  50  years  ago.  Researchers  and  industry  have 
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attained  multi-level  security  systems  but  the  costs  are  still  tremendous.  The 
Worldwide  Military  Command  and  Control  System  installed  many  Gemini 
Computers  running  GEMSOS  in  front  of  large  IBM  mainframes  each 
processing  different  types  of  classified  and  unclassified  documents  at  a  very 
significant  cost  compared  to  what  most  corporations  could  afford. 

Industry  is  developing  trusted  databases,  trusted  networks,  and 
trusted  computer  security  controls  which  will  be  present  in  the  Secure  Data 
Network  System.  Although  still  in  the  research  and  development  phase,  SDNS 
may  become  a  great  jump  forward  for  security.  Embedded  encryption  internal 
to  PCs  with  automated  public  key  administration  will  provide  the  basis  for  a 
totally  new  way  of  operating  with  classified  data. 

b.     Public  Key  Encryption 

An  important  part  of  the  architecture  is  the  ability  to  transmit 
encrypted  data.  According  to  Barker  (1991),  a  hybrid  of  the  secret  key  and 
public  key  techniques  is  recommended  when  secrecy,  integrity,  and 
authenticity  are  desired  because  secrecy  can  best  be  provided  by  using  a  secret 
key  but  authenticity  is  best  provided  using  a  public  key.  E-mail  and  EFT 
require  non-repudiation  of  origin,  which  occurs  when  authenticity  can  be 
proven  to  a  third  party  and  to  the  receiver  of  the  data.  Presently  organizations 
wish  to  use  public  key  techniques  for  both  non- repudiation  of  origin  and  for  the 
distribution  of  secret  keys.   NIST  is   developing  EDI   data  elements  and 
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segments  to  allow  the  use  of  the  public  key  for  EDI,  according  to  Barker 
(1991). 

The  public  key  algorithms  provide  non-repudiation  of  origin  of 
the  message  by  computing  digital  signatures.  Digital  signatures  are  a  function 
of  the  signed  data  and  the  key  used  to  sign  the  data.  The  private  key 
calculates  the  digital  signature  and  the  public  key  verifies  the  digital 
signature.  A  signed  message  contains  both  the  signed  data  and  the  digital 
signature.  The  originator  of  the  message  computes  the  digital  signature  by 
using  his  private  key.  The  receiver  of  the  message  uses  the  public  key  to  verify 
the  signature.  If  the  receiver  verifies  the  signature  then  he  knows  that  the 
sender  of  the  message  is  really  that  person  because  no  one  else  could  have 
calculated  the  digital  signature  since  only  the  sender  knows  the  private  key. 

The  third  party  used  to  verify  the  digital  signature  is  the 
certification  authority.  The  certificates  used  by  the  authority  contain  the 
identity  and  the  public  key  of  the  certificate's  owner  and  the  digital  signature 
on  the  data  computed  using  the  Certification  Authority's  private  key.  The 
certification  authority  is  trusted  to  not  alter  or  falsify  certificates  exchanged 
between  users.  Each  user  gives  his  public  key  to  the  certification  authority 
which  gives  its  public  key  to  each  user.  The  certification  authority  then  signs 
and  issues  a  certificate  to  each  user  using  its  private  key. 
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c.     Neural  Networks  For  Script  Entry  or  Voice  Entry 

Optical  character  recognition  can  make  sense  of  text  on  the  page 
with  approximately  80%  degree  of  accuracy,  but  near  100%  accuracy  can  be 
expected  with  a  neural  network,  according  to  the  International  Joint  Neural 
Network  Conference  (1991).  Hand- writing  recognition  lets  you  put  annotations 
on  documents  and  notes.  OCR  is  best  for  printed  text  as  long  as  the  OCR 
system  recognizes  the  dissimilar  typefaces  and  vocabularies  or  two  letters 
touching  each  other.  Most  U.S.  companies  cannot  perform  handwriting 
recognition  except  for  hand  printed  block  letters.  However,  Tazelaar  (1991), 
states  that  a  small  Soviet  company,  ParaGraph,  has  a  product  called 
CalliGraph  that  dissects  handwriting  into  component  parts  such  as  loops, 
curves,  angles,  and  their  sequence.  The  product  is  pen  based  using  a  graphics 
tablet.  The  components  are  compared  to  different  letters  made  up  of  similar 
components  and  compared  to  a  word  list  to  find  a  valid  word.  As  long  as  the 
word  is  on  the  list,  CalliGraph  will  recognize  the  word. 

In  the  USAA  example  cited  earlier  under  document  imaging,  the 
use  of  a  neural  net  to  fully  automate  the  task  of  sorting  documents  by  type  will 
result  in  documents  and  faxes  being  routed  to  their  destinations  even  faster 
and  more  economically  because  another  human  can  be  taken  out  of  the 
workflow.  As  the  network  trains  the  accuracy  will  improve  until  no  human 
intervention  will  be  needed.  Using  neural  networks  for  business  document 
forms  would  be  most  benefical  because  using  a  process  called  forms  subtraction 
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would  eliminate  the  storage  of  billions  of  forms  and  just  keep  the  data  used 
with  the  form.  According  to  Wright  (1991),  in  the  future,  intelligent  systems 
will  be  able  to  determine  what  is  data  and  what  is  background  on  the  form. 
Hand  printed  information  or  hard  to  recognize  machine  print  will  be  separated 
from  the  background  by  the  intelligent  system.  Fifth  generation  languages  use 
natural  language  processing  and  sixth  generation  languages  will  use  voice 
itself  to  execute  commands  and  process  data.  Entry  into  forms  databases  by 
voice  will  greatly  speed  up  forms  entry.  For  example,  an  individual  could  call 
his  bank  and  instead  of  waiting  for  the  Voicemail  selections  and  entering  a 
number  on  the  touchtone  phone  the  individual  may  talk  to  the  Voicemail  just 
as  if  a  human  had  been  there  processing  data  and  keying  it  into  a  computer 
system. 

E.      EXAMPLE  PROJECTS 

During  the  course  of  the  author's  research,  several  projects  involving 
CALS/CE  and  EC/EDI  were  competing  for  funding  from  DLA.  This  research 
will  examine  three  of  those  projects  which  demonstrate  the  need  for  the 
proposed  interchange  architecture. 

1.      DLA  X.400  On  The  IGP  Platform 

DLA  System  Automation  Center  Central  Design  Activity  in 
Columbus,  Ohio,  is  working  closely  with  the  Retix  Corp.  to  develop  a  1984 
X.400  Implementation  on  the  IGP  platform.  According  to  Asgher  (1991),  on 
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June  6,  1991,  a  successful  test  was  conducted  using  a  386  PC  running 
Interactive  UNIX,  AT&T  3B2/600G  running  AT&T  UNIX,  and  a  Gould  X12 
running  a  LINX  EDI  program.  The  test  demonstrated  that  an  EDI  transaction 
can  be  sent  from  a  DOD  environment  with  TCP/IP  to  the  IGP  and  translated 
to  an  X.400  protocol  as  a  user  agent,  then  sent  to  a  message  transfer  agent  386 
PC,  then  sent  across  an  X.400  EDI  VAN  network  to  an  ABC  program  which 
delivered  the  EDI  message  (Figure  4).  The  next  phase  in  this  project  calls  for 
eliminating  or  substituting  for  the  386  PC  by  running  the  LINX  EDI  program 
and  the  Message  Handling  System  software  on  the  3B2  connecting  it  to  the 
X.400  network.  Asgher  (1991)  stated  that  X.400  will  have  a  practical  limit  on 
the  size  of  the  file  transmitted  but  that  it  will  be  very  large  and  should  handle 
most  Government  functions.  White  (1991)  similarly  stated  that  for  the  very 
large  files  exceeding  10  megabytes  FTAM  maybe  better  to  use  than  X.400. 
Retix  has  based  its  Message  Handling  Software  on  Unix  based  platforms  but 
will  be  porting  it  to  DOS  based  platforms  in  the  near  future  according  to  White 
(1991).  The  Gould  minicomputers  in  DLA  were  procured  in  1986  and  are 
obsolete.  The  AT&T  3B2  minicomputers  in  the  Air  Force  and  DLA  were 
procured  in  1989  and  are  two  generations  of  hardware  behind  industry.  The 
focus  of  this  project  for  the  future  should  be  portability  to  any  hardware 
platform  to  support  the  OSI  environment. 
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DLA  X.400  ON  THE  IGP  PLATFORM  PROOF  OF  CONCEPT 
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Figure  4.  DLA  X.400  on  the  IGP  Platform  Proof  on  Concept. 

2.      National  Procurement  Pilot  Project 

The  second  project  this  research  discusses  involved  the  U.S.  Army 
Materiel  Command  Systems  Integration  and  Management  Activity  in  St.  Louis, 
Missouri.  The  name  of  the  project  is  National  Procurement  Pilot  Project. 
According  to  Thrash  (1991),  the  main  thrusts  are:  integrate  X12  850,  841,  and 
858  transaction  sets  at  the  Tank  Command  with  several  commercial  trading 
partners;  perform  a  single  MODELS  file  transfer  and  generate  system  modules 
for  in/out  MODELS  processing;  OSI  architecture  implementation  on  multi- 
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platforms;  and  overlay  modular  EDI  as  Procurement  Early  Development 
System  is  implemented.  The  software  platform  at  DLA  Central  Design  Activity, 
Columbus,  Ohio  will  be  a  primary  consideration  because  it  has  already  been 
conceptually  proven  and  is  OSI  based.  The  availability  of  the  Lawrence 
Livermore  National  Laboratories  IGP  and  its  lengthy  development  schedule 
would  essentially  delay  this  project  for  an  unacceptable  period.  The  schedule 
given  by  DLA  for  the  development  of  the  Lawrence  Livermore  National 
Laboratories  IGP  shows  that  it  will  be  three  more  years  until  it  should  be 
ready  for  fielding. 

3.     Highly  Automated  Office 

The  final  project  discussed  contains  most  of  the  multimedia  and 
hypermedia  issues  this  research  presented.  The  U.S.  Army  Corps  of  Engineers 
(USACE)  proposes  a  project  entitled  "A  Proposal  to  Enhance  Electronic 
Commerce  Through  Creation  of  an  Automated  Office  Environment."  According 
to  Tisel  (1991)  the  project  keys  on  an  application  called  Knowledge  Worker 
System  (KWS)  which  will  operate  under  Windows.  KWS  is  an  electronic 
performance  system  support  groupware  product  that  is  based  on  expert 
systems,  multimedia  databases,  and  hypertext  through  dynamic  data 
exchange.  KWS  has  a  unified  interface  that  integrates  the  whole  set  of 
productivity  tools  used  by  knowledge  workers.  The  entire  workflow  will  be  re- 
engineered  and  coordinated  throughout  the  organization  by  automating  access 
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and  retrieval  of  multimedia  information  through  a  distributed  environment 
and  EDI. 

F.      IMPLICATIONS 

The  long  awaited  paperless  office  may  be  attainable  by  the  year  2000  in 
DOD  if  the  proposed  interchange  architecture  is  adopted.  If  technological 
breakthroughs  occur  at  the  same  rapid  pace  as  in  the  1980s,  and 
standardization  through  open  systems  accelerates,  the  goal  of  completely 
changing  the  way  we  do  business  or  the  paperless  office  may  finally  become 
reality.  New  products  called  multimedia  development  kits  or  hyperwriters  will 
become  widely  available.  For  example,  Microsoft  will  use  multimedia  PCs  and 
Windows  with  multimedia  to  provide  a  platform  for  developing  multimedia 
applications  and  title  developers.  Several  functions  can  occur  such  as  recording 
voice  and  music,  creating  training  manuals  online,  adding  voice  annotation 
features  to  a  business  application,  and  editing  color  bitmaps  and  palettes.  The 
application  programming  interface  allows  the  applications  to  perform  even 
more  functions  such  as  waveform  audio  recording  and  playback,  musical 
instrument  digital  interface  music  played  on  internal  or  external  synthesizers, 
media  control  interface  for  controlling  peripherals  like  videodisc  and  videotape 
players,  animation  playback,  managing  multimedia  data,  and  high  resolution 
timer  services.  The  Viewer  and  Viewer  Author's  Toolkit  let  the  developer 
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prepare  text,  images,  audio,  hyperjump  from  text  to  graphics,  search  hypertext 
documents,  and  hyperjump  from  bitmap  images  to  text. 
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VI.  CONCLUSIONS  AND  RECOMMENDATIONS 

A.  CONCLUSIONS 

Advances  in  interoperability  and  connectivity  have  changed  our  way  of 
doing  business  by  going  from  islands  of  automation  to  application-to- 
application  processing.  Physical  connectivity  and  file  transfers  between 
computers  are  no  longer  enough  to  satisfy  the  needs  of  the  ever  growing 
number  of  users  and  organizations.  This  will  provide  a  foundation  upon  which 
TQM  of  IS  is  implemented.  TQM  of  IS  dictates  that  technology  must  be  applied 
to  the  workflow  not  the  workflow  to  the  technology.  The  OSI  architecture  and 
standards  allow  applications  to  interface  seamlessly  across  homogenous 
networks.  The  use  of  the  interchange  architecture  proposed  by  this  research 
will  allow  multimedia  and  hypermedia  applications  to  seamlessly  interface 
across  heterogeneous  networks  worldwide. 

B.  RECOMMENDATIONS 

Adoption  of  the  standard  interchange  architecture  for  multimedia  and 
hypermedia  data  is  the  best  strategy  to  follow  to  successfully  implement 
EC/EDI  and  CALS/CE.  Anything  short  of  using  OSI  protocols  from  the  start 
will  be  a  waste  of  dollars  and  place  DOD  further  behind  industry.  All  on  going 
projects  should  be  examined  for  use  of  OSI  protocols  and,  if  they  cannot  use 
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them  within  a  short  period,  should  be  reconsidered.  All  projects  should  be  re- 
engineered  first  before  trying  to  apply  technology  to  the  solution.  The  DOD 
suite  of  protocols  should  no  longer  be  supported  and  the  transition  to  GOSIP 
should  take  place  as  soon  as  possible.  Industry  has  made  the  switch  to  OSI 
and  unless  the  Government  follows  quickly  they  will  fall  further  behind.  DOD 
cannot  afford  to  wait  for  the  IGP  solution  to  add  X.400  in  1994  to  a  specific 
platform.  The  best  option  currently  is  to  use  1988  X.400  VANs  which  support 
EDI  from  various  PC  platforms.  Continuing  support  for  TCP/IP  and 
SMTP/X.400  gateways  will  only  prolong  the  use  of  a  proprietary  protocol  and 
delay  the  transition  to  OSI.  DCA  should  grant  waivers  to  any  organization 
needing  EC/EDI  and  let  them  pay  for  a  dedicated  leased  high  speed  access  line 
to  an  X.400  VAN. 

C.      RECOMMENDATIONS  FOR  FUTURE  RESEARCH 

1.      Electronic  Performance  Support  System 

The  next  logical  step  beyond  the  interchange  architecture  for 
multimedia  and  hypermedia  is  to  develop  an  information  software  system  to 
use  the  capabilities  provided  by  the  architecture.  The  EPSS  can  harness  high 
powered  workstations,  super  mainframes,  touchscreens,  multimedia  platforms, 
object  oriented  platforms,  authoring  systems,  databases  which  stores  data, 
various  kinds  of  text,  scanned  photographs,  etc.  Hypertext,  expert  systems,  and 
multimedia    integration    can    provide    users    with    immediate    access    to 
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information,  advice,  guidance  or  assistance,  training,  and  other  tools  using  just 
the  computer  without  any  other  human  assistance.  Smart  systems  that  are 
problem  solvers  for  users  may  provide  the  return  on  investment  that 
executives  have  been  yearning  for  and  hoping  that  information  systems  would 
have  provided  long  ago.  EPSS  demonstrates  the  TQM  of  information  systems. 

2.      Object  Oriented  Programming 

The  hypermedia  interchange  architecture  allows  the  user  to  function 
at  the  application  level  without  being  concerned  with  the  lower  level  functions, 
standards,  and  telecommunications  infrastructures.  This  architecture  may 
provide  the  necessary  infrastructures  to  facilitate  true  object  oriented 
programming  in   application  development. 

The  object  oriented  document  approach  uses  object  linking  and 
embedding  for  documents  allowing  data  type  independence. 
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APPENDIX:  X12  SUBCOMMITTEES 


1.  X12C  Communications  &  Controls 

2.  X12D  Education  &  Implementation 

3.  X12E  Product  Data 

4.  X12F  Finance 

5.  X12G  Government 

6.  X12H  Materials  Management 

7.  X12I  Transportation 

8.  X12J  Technical  Assessment 

9.  X12K  Purchasing 

10.  X12L  Industry  Standards  Transition 

11.  X12M  Distribution  &  Warehousing 
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